what color should this button be?
we can only do x and y, but not z, before the deadline. can we live with that?
sales requested a, b, and c. which should we do?
the ceo had a new idea and asked if it’s worth pursuing.
as product builders, we make decisions all day every day.
how do we know if they are any good?
the heath brothers, indecisive, outline the 4 villains of decision making:
- we look too narrowly at a problem
- we look for evidence that supports our beliefs
- we let short-term emotions affect our decisions
- we are overconfident
kahneman and tverskyspent the better part of a decade exploring the common mistakes we make, including theconfirmation bias, thehindsight bias,thestatus quo bias, theavailability heuristic,anchoring, and so much more.
the research seems to indicate that we aren’t very good at making decisions. so what are we to do?
fortunately, the research also suggests ways we can design thoughtful decision making processes to overcome some of these shortcomings.
before we dive into how, let’s first identify the eight critical decisions required when creating great products.
it all starts with goal-setting. a good goal allows you to trust that you are on the right path and charge down it as fast as you can. it allows you to put blinders on to everything else and relentlessly focus on the one thing that matters. your goal.
however, if you do this with a bad goal, it can be catastrophic.
how you identify and select goals is one of the most important decision making processes in building great products.
if you are making ad-hoc decisions about goal setting, you are probably charging down too many different paths. –tweet this
most companies overlook this process all together. they leave idea generation to the founders or to the product team or to the sales team. they just hope it gets done.
thanks to creativity research, we know that more ideas lead to better ideas. we also know that more ideas that are all similar to each other don’t help. they need to be categorically different.
and unfortunately, brainstorming as we generally know it,simply doesn’t work.
people generate more, better ideas individually than they do in groups. –tweet this
and yet, most companies still rely on brainstorming to generate good ideas.
it’s hard to build great products without generating a lot of diverse ideas. and not just during the early stages of the product. it’s important throughout the entire lifecycle of a product.
so now that we’ve got a pile of ideas, how do we know which ones are good? which ones should we pursue? where do we invest our time and resources?
outlining evaluation criteria and sticking to it is one of the most important jobs of the product team.
doing so allows everyone to participate in the idea generation process. it creates a sense ofprocedural justice,which is critical for keeping people motivated and engaged.
more people generating ideas leads to more ideas which leads to better ideas. having clear evaluation criteria makes this happen.
not to mention, if you can’t identify the ideas worth pursuing, you won’t be successful.
and yet, too often product teams make intuitive judgements in the moment. this simply doesn’t work.
i can already hear some of you argue, we’ll run tests to decide which ideas to pursue.
this is far and away the worst side-effect ofthe lean startup(and it’s not eric’s fault). it’s yours for not actually reading the book.
stop throwing spaghetti at the wall. you can’t test everything. there aren’t enough hours in the day. you have to decide which are the most important things to test, when, and how.
this includes what to a/b test, what to usability test, when to run a survey, when traffic analysis is good enough, what data to look at and when, and so much more.
but on top of knowing what tests are good for which situations, teams need to identify their own standards.
experimentation serves two purposes. first, it helps us learn what works and what doesn’t work. second, it helps us get buy-in from key stakeholders and build momentum.
startups don’t like to focus on that second reason. but it matters.
you might believe jakob nielsen that youonly need 5 usability participantsto get good data, but if your engineers think 8 is the minimum, you might want to just run 3 more participants through the study, rather than arguing with them about the validity of the results.
identifying your own experimentation processes and standards can go along way toward establishing norms for how your team will learn and for building confidence in what you learn.
so we’ve whittled our idea pile down to a handful of well-tested concepts that meet our evaluation criteria. how do we decide what to build first?
do you build what’s easiest first?
many teams misinterpret agile to mean, yes, you build what’s easiest first.
the problem with this is you end up with a product full of the easiest things and not the best things.
again, this isn’t a problem with agile. it’s a problem with people’s interpretation of agile.
agile simply encourages you to build iteratively.
the concept of an mvp is to build the smallest product that validates your biggest assumption, not to build the easiest / quickest product. –tweet this
teams need to identify good ways of uncovering these assumptions and prioritizing experiments and development that validate them as quickly as possible.
rarely is an idea ready for implementation. it almost always requires some design before it’s ready to be implemented. i don’t just mean ui or ux or visual design. i mean product design. but that’s not a decision-making process, that’s an art. we’ll tackle that in the third pillar when we discuss team and individual skills.
in the meantime, let’s assume we know what we want to build next.
now, it’s up to the engineers to build. we are done, right?
anyone who has ever built a product knows that’s simply not true.
engineers can rarely build exactly what we ask for. nor should they.
we overlook things all the time. sometimes what we ask for isn’t very good. often times, the way we ask them to build is downright shoddy.
you should be partnering with engineering every step of the way. and that often means being involved in deciding how the product gets built.
the requirements you send to engineering should be the beginning of a conversation. a conversation that unravels as they build. –tweet this
the more engrossed in the code the engineers get, the more questions they are going to have, the better they are going to understand what’s possible and what’s not.
does your team have a good process for managing these conversions? or are you like most teams, simply writing user stories, calling it agile, but really throwing them over the wall in a mini-waterfall approach?
if you aren’t talking to engineers every day about what they are building, you probably need to rethink how you are building product.
i used to tell our engineering team, if you don’t know how we are going to measure success, don’t build it. i wanted them to hold me accountable to knowing why we were writing every single line of code.
measuring outcomes is absolutely critical. it tells us when our assumptions are wrong. i love it when my assumptions are wrong. it tells me that i think about my product differently than my users. and it’s critical that i uncover why.
but it’s hard to know what to measure, when, and why. getting this process right is one of the hardest things a product team does.
the goal isn’t to measure anything and everything. it’s not to look at vanity metrics to make us feel good about ourselves. it’s to truly understand what impact we are having. this process requires a lot of thoughtful design.
the first seven processes, if designed well, will help you build great products. but they aren’t enough. you also have to bring people along with you.
it’s absolutely critical that you know what to communicate to who every step of the way. you have to set expectations appropriately. you have to do this internally with your sales team, your engineering team, your executive team; and you have to do it externally with your customers and your end-users.
even if you get the first seven processes right, if you overlook communication, you’ll have a hard time succeeding.
it’s simple, right?
get these eight processes right and you’ll be on your way.
nobody said building great products was going to be easy.
but don’t worry, starting on monday, we’ll dive deep on each of these processes.
we’ll draw on decision research, behavioral economics, learning theory, and so much more to design thoughtful processes in each of these areas.
don’t miss out,subscribe to my mailing listto be notified when there are new posts.