Piecing the Product Puzzle with Four Essential Questions

Imagine you’re on a treasure hunt. There is a pot of gold somewhere, sitting snugly in the Earth’s womb, waiting to be dug out. You’ve been given a map that leads you there. But there’s a hitch. The map is a jigsaw puzzle! The pieces are all over and you have to put them together to reach the gold.

Welcome to the modern-day product development. Your skill in piecing the map is your skill as a product manager and the gold hidden in earth is the success of your product and happiness of your team.

And if the madness of managing products wasn’t enough, the changing models for product execution- Scrum, Kanban, XP, Waterfall- seem to have added to the entropy, taking it a notch higher.

So, I’ve created a framework for myself which is agnostic to many things- model, strategy, domain, and product age. That is, it doesn’t matter whether your team is following Scrum, Kanban or traditional Waterfall model. It doesn’t matter if you are a new entrepreneur bootstrapping the first product or if you’re working on the strategy of one that is on it’s way to eternal glory.

The framework I use, gives the view at 10,000 feet so disentangle from the noise and put things in perspective and in relative priority.

Start With the ‘Why’

If you’ve missed this talk by Simon Sinek on ‘Start with Why’ then I don’t know which rock you have been living under. Be it a person or an organization, the ‘Why’ is your pole star, your guiding light.

Extending the same philosophy to building products, knowing the ‘Why’ of what it is that you want in the product creates the essential difference between ‘empathetic implementation’ vs ‘mindless execution’.

Additionally, many times requirements come as a wishy-washy wish list or as a reaction to a current situation, instead of being born out of a well thought out product strategy. Needless to say that it can result in wasting both your effort and time.

So I find that whenever requirements are shared, it’s important to ask a few questions that help you understand it’s need and value.

• Why is this a good problem to solve?
• Why do we have to solve it now? Why not later?
• Why was it not done before?
• What would the world look like after it’s solved?
• Are we solving something new or are we improving an existing situation
• Whom are we doing this for? Whom are we not doing it for?
• Why do ‘I’, yes ‘I’, care to solve this? What is my main motivation? Profit? Outreach? Impact?

And questions are only as good as the time at which they are asked. So ask these questions when -

• You are at the start of the project/requirements phase.
• Whenever someone is not convinced about what they are doing.
• When there is a conflict between ideology and implementation.

The last one is my personal favorite as it helps to break the clouding of judgement due to pressure of deliverables.

These questions can help you answer the most essential questions of priority. So Everyone in the team should be asking them- from Stakeholders to the Development team. Because without the ‘Why’, life is meaningless!

Define the ‘What’

There is a long road from ideation to action. And this road is defined by the ‘What ‘. When effectively broken down, it gives you the entities, attributes, and capabilities- what can be done and what can’t be done — by your product.

The ‘Whats’ are your building blocks.

What’s in it for you? Well a whole lot as you will find below.

• What is the ecosystem where your product will reside? What domain, sector and geography?
• What are the entities, processes and players in your system? Ask the stakeholders and business teams to define them clearly to avoid any communication gap.
• What are the systems — internal and external — and what are their dependencies? Ask the development team to identify these because it will reveal complexity, feasibility and dependence sooner rather than later.
• What is your taxonomy? If you don’t have it, create one.
• What representation techniques will you use?

So, again, when should you ask these?

• At the start of product.
• Every time you hear a question that becomes ‘frequently asked’
• Whenever you have to share something that you know can easily get ‘Lost in Translation’.
• Whenever you introduce a new term or idea.

In short, whenever you create and define requirements to solve the ‘needs’ and the ‘why’, you must define the ‘What’ to remove any ambiguity.

Decide the ‘When’

If you’re a cricket fanatic or a stand-up comedian, the skill of ‘timing’ is what determines your success or failure. Timing is the ability to predict and place your shots or punches in the right place with the right force.

And, just like in Sport and Comedy, timing in product development is not so much about the actual time itself, but more about the placement and priming.

So instead of trying to be an Oracle to predict the aupicious ‘Time’, ask these questions for placement and priming

• What is of essence right now? Feature or Timeline?
• Do we need to do frequent updates or less frequent? This ties to nature of the product if it requires a lot of ‘learning’ or is easily discoverable.
• When was the last big product update? Are we going too long without doing anything new? Are killing it with analysis paralysis?
• When was the last time we released features that came as user requests or feedback? If you are releasing product updates and not catering to user feedback, they will lose trust and not return.
• If we are doing something specific to a time of year or event, have we created enough buzz for that?
• Should we release in a lean phase or competitive phase? The answer could be different for different products.
• Is this really needed right now?

And the critical ‘When’ of these ‘when’ questions are -

• At the product kick-off
• When making the Product Roadmap
• In every grooming cycle
• When you spot a sudden demand or change in market
• Whenever there is a tussle between scope and timeline

Placement and priming will determine whether you were the idea generator, early starter, someone who joined the band wagon or someone who totally missed the bus.

End with ‘How’

Now before the purists admonish me, let me say one thing — a Product manager does not need to know each and every intricate detail of the ‘How’. You don’t have to know if the application uses Lazy loading or double check lock. But you do need to know a few essentials aspects that impact the product’s credentials (all the ‘abilities’), revenue and future prospects.

In short, you need to know those aspects of the ‘How’ where the problem/need marries the implementation.

So what are some of the ‘Know-Hows’ you should ask?

• What is the stack that your product uses. Ask the team for its ‘Why’ (see, how we circle back to Why in every sub loop)
• What kind of learning curve does it require? How easy or difficult is it to get people based on this skill set?
• How is the community and support around it? Afterall, you don’t want to be dialing any helpline number in an emergency only to be told ‘Number does not exist’
• How stable is it? What is the platform’s maturity period?
• Does it scale up? Or is it known to collapse past the MVP stage?

And like always, when should you be asking these questions?

• During early stage/feasibility analysis for the product — be it a new product altogether or for some new requirements which is yet unexplored.
• Every Sprint during technical design and infrastructure planning
• Anytime you hear this phrase too often ‘We cannot do x, y, z due to limitations of our system’ , ‘This is not supported in our system’,

Some of these may look like common sense, but then, so are most puzzles. Being able to piece things together in the daily tussle of delivery vs strategy is what will help you deliver as per your strategy and not sacrifice strategy over delivery.

I wrote this blog for our Medium Publication- Unboxing Product Management. The publication is a weekly column by leaders of Quovantis to share their learning and knowledge with the world. If you liked reading the blog, clap your heart out and help others find it.