you find yourself in a conference room with your product team. the white board is covered with sketches. you have an idea that everyone is excited about.
you mapped it out. you have a plan. your engineering team is anxious to get started.
this is what makes building products fun – the appeal of the next big idea.
however, there is a problem.
your level of confidence in a new idea has no basis in reality. –tweet this
confidence is a symptom of how well your brain can construct a coherent story. coherence, however, does not necessitate truth.
research in motion was confident that their secure network set them apart, gave them a competitive edge. this was a coherent story, but it wasn’t true.
remember when aol was everyone’s gateway to the internet? aol was confident a walled-garden approach was best. this also wasn’t true.
you too will make assumptions as you build your product. the key is to surface those assumptions and ask yourself, “how can i know if this is true?”
balance confidence with doubt
wisdom = knowing + doubting –tweet this
it’s hard to balance confidence in what you know with the possibility that you might be wrong.
but it’s the attitude you need to develop if you want to avoid the fates of research in motion and aol.
acknowledge hard truths
you can’t predict the future.many analysts, pundits, and so-called experts have tried. their records are terrible.
you will be wrong.it happens to the best of us on most days.
you don’t know what’s best for your customers.even with countless hours of user research and deep domain knowledge, your customers will always surprise you.
i’ll never tell you to skip the research or disrespect your domain knowledge, but you need to balance both with the reality that customers are people, ever-changing, complex, and ultimately unknowable.
you can’t know what you should build next.i know it’s the question you face each and every day. i know it’s what you get paid to do. and i know it can be terrifying to admit you have no idea what should come next. but it doesn’t mean it’s not true.
most of us have a long list of what could come next. could is not the same as should.
you have no idea when what’s next will be delivered.i’ve never met a product team that had confidence in their timelines. i’ve never met an engineering team who hit deadline after deadline.
engineering is an unpredictable task. we need to stop acting as if that’s not so.
make wise product decisions
instead of writing 50 page product requirement documents – a methodology that assumes we know exactly what we should build before we’ve even started –build iteratively. assume you might be wrong and build it into the plan.
instead of telling your customers what’s on your roadmap,engage them in the conversation. collaborate with them. assume they know more than you ever could and devise methods to tap into that.
instead of building ten features to find out only three worked,run ten experimentsand build only the three that worked.
assume that most ideas aren’t going to work and mitigate that risk by experimenting before you build. –tweet this
shift to an experimental mindset
for the agile-lean-customer development advocates, you may be reading this and thinking, “of course. this is obvious.”
but take a minute and consider the last ten product changes you made. how many were supported by experimentation? how many delivered onthe expected impact?
and for those of you who are thinking this would never work at my company, take a minute and consider what would happen if your competitors started working this way. how quickly would your company follow suit?
thanks tothe lean startup,we are talking about building support for our ideas, for running experiments, and for making room for doubt in our decision making. but it’s one thing to talk about it, it’s much harder to start doing it.
if you need help shifting from talking to doing, send me an email at teresa at producttalk dot org and let me know where you are facing challenges. i’ll do my best to address the most common obstacles.
and if you want to get future posts delivered right to your inbox,subscribe to the 瑞士vs喀麦隆水位分析 mailing list.
this post appeared first onlinkedin pulse.