Human-focused Products need Human-focused Inputs
Image Credit-https://unsplash.com/@edoering

Human-focused Products need Human-focused Inputs

A constant question that a product manager lives everyday with is—what to build next? For a short term he can find the answers to the biggest question on which his career relies but most of the times you can find him searching for the right answers to this question.

He gets ideas from engineering teams, business owners, customers, and C-level executives with their opinions.

But how should he make the right decision?

Obviously, he can’t make everybody happy, in all that chaos he shuts himself down and goes to flip some pages of old school textbooks forgetting the fast-changing dynamics of the world. He looks for a tool or techniques or a framework which can help him. He searches for one but comes across many like, RICE, WSJF, MoSCoW, Kano etc.

Back in 2000 when organisations used to follow the waterfall methodology for software development, Microsoft released Windows ME and in 2004, they announced that they don’t want to support it anymore and finally ended the support in 2006. An operating system is such a complicated piece of software and back then Microsoft’s business relied on this product but what happened that they made up their mind to abort mission Windows ME in 2004. It was a complete flop!

Then came the agile methodology, which says, develop in smaller batch sizes, write code for couple of weeks, run system demos take feedback from the customers and improve in iterations instead of writing code for months and months and months, and later figuring out that nobody needed those features or products.

But most of the people missed an important point here agile is not agility. Its whole purpose is to stir the thought process to create a solid product definition. To focus on product discovery before delivery. These days most people focus to maintain the speed of delivery and very less effort is being put into the product discovery.

The fancy framework

In an ideal world, I have 2+2=4 we all know it, we have studied mathematics. But imagine a scenario, where I need the output as 4 and don’t know how to achieve it. ?Similarly, frameworks work on the assumption that you have already done the discovery on what to work on next. Frameworks are output driven.

You can’t simply evaluate the reach and impact without properly vetting to know if it were the right things to work upon and if you have not spoken to your customers or users then chances are that you have very less information and hence, confidence.

Prioritisation is not easy

Prioritisation of work is not a linear equation to solve, it is not as simple as doing 2+2. Even if you have a framework, it is not as straight as ticking the boxes on your checklist. There can be multiple, back & forth discussions on feature prioritisation during road-mapping, ideation, and development.

The key here is, whenever you start prioritising start with your objectives. This allows you to figure out how the work you are going to pick will help you meet your goals. Once you have finalised the initiatives which fit your objectives, it is time to figure out the ones which will give you give you the desired outcome with the greatest impact.

Opportunity Solution Tree

So, the basic question we are trying to answer is- will this help me achieve my desired outcome? There is a visual representation method called Opportunity Solution Tree (OST) that can help. It has 4 key elements:

  • Outcome- What we want to achieve?
  • Opportunity- Why we need to build the solution.
  • Solution- Ways of implementing that opportunity.
  • Experiments- Ways to test a solution

No alt text provided for this image

?Once you have figured out the opportunities, solutions and experiments it can give you a better idea of:

  • What to work on & why?
  • Is it worth pursuing?
  • How to measure success?

The baseline

Prioritisation framework can only help you to understand and visualise the information that is already in front of you. But before that you must work hard to mine that information. Because there is so much more to decide on what to work on next than just going with the ‘whatever fits to the framework’s input’ mindset. Frameworks can help enable conversations between teams, but they can’t help you to make decisions for you. Just think about it, if a framework could make a decision for us, why would there be a need for a Product Manager anyway? Above all, frameworks lack the most important aspect of Product Management- empathy.


要查看或添加评论,请登录

社区洞察

其他会员也浏览了