A monthly review meeting is in order and it has just come to light that 4% of your everyday e-commerce marketplace’s active (app opening) users place orders daily.
CEO: How do we make it 20%? 🤔
Product Manager (PM): Well, we know that discount offers work the best in the offline market to drive sales, so we should build support for offers to improve conversion significantly.
Marketing Manager: Yes, we can get discount offers on products by convincing our suppliers that they would get more orders.
PM: That would be great. We can start building the offers feature next sprint onwards.
CEO: And this will increase conversion from 4% to 20%âť“
PM: It is a big jump, but we know this is effective. So, we should at least be able to double it.
CEO: Alright! Let’s do this.
The conversation seems reasonable. Everyone is aligned. Building an “offers feature” seems fair. But this approach of deciding what to build is far from optimal.
What’s wrong with this approach of deciding what to build?
We can tell what’s wrong by asking these questions:
- Are there any bigger problems that are blocking users to convert? E.g. Users facing payment failures, users not being able to use the app if they are not able to understand English.
- Even if there’s no clear problem, are there some better examples of how other companies have tried to solve for conversion? What worked the best and what did not work?
- Are there more/ better options that we can think of, for our users, so that we can compare better before we close on one feature?
- How long will it take to launch this feature? Is there something else we can do to create a similar impact but much faster?
- Is building this feature aligned to our vision or strategy? E.g. For a convenience-first platform, providing more/ better convenience services like faster delivery or easy returns can also increase conversion and will be more aligned to its focus areas.
In the meeting itself, the product manager jumped to deciding to build without considering these questions.
Due to this quick decision, they might be missing out on a significant opportunity on the table or might be delaying the impact that could have come faster. Or worse, they might be building something that may not align with the long term vision and strategy, which will lead to that feature eventually being dropped.
What they should have actually done is to take some time to do product discovery and then address the question that the CEO asked.
One part of this product discovery is problem discovery - identifying the problems to achieve a particular goal. The second part, which is more closer to this decision of what to build is product solutioning.
What is product solutioning?
Putting it simply, product solutioning is the process of solving identified problems and identifying a product to build that will solve those problems.
Why do we need to do product solutioning?
Product solutioning is done to ensure two key outcomes:
- To increase our chances of success while solving a problem (effectiveness of the solution).
- To create maximum impact in the shortest possible time.
It also ensures that we:
- Avoid building products that are likely going to not create impact or will not be used by users.
- Learn from other products and do not spend time building products which will prove to be ineffective- time/ opportunity loss.
- Avoid building products that do not align with our long term vision strategy.
- Widen our options and then select the right one to maximise impact and minimise time to launch.
What are the key steps for product solutioning?
Before we start product solutioning, we need a clearly articulated problem statement. This problem statement comes from problem discovery. Let us take one example here:
Users from tier 3 & 4 cities/ towns find it difficult to navigate the Meesho app as they do not understand english well and are not familiar with e-commerce terms like cart, checkout etc.
Now, our product solution-ing activity will involve the following steps:
- Competitive Research
- Brainstorming
- Defining guiding principles
- Prioritisation
The first two steps help us diverge and widen our options while the last two steps helps us converge on a few ideas and finally decide what to build.
Competitive Research
Now, continuing with the same problem statement, we will start our product solution-ing with competitive research.
- Look for how other players in the same or similar markets have solved the same problem.
- Reverse engineer the user problems as per the platform persona.
- Build hypotheses on why these platforms would have built those specific features
- Why would those features have worked for their persona?
- Validate/ invalidate hypotheses through primary and secondary research
Example for our problem
Red (Xiaohongshu) in China has a live stream product on the platform where the streamer can interact with the shoppers in vernacular language for shopping as well as guide them for easier navigation.
Brainstorming
Brainstorming is essential to product solutioning as it is the step where we go all out (and out of the box) on ideas. Here are some tips to conduct effective brainstorming:
- Start with sharing the problem and your findings from competitive research
- Focus on quantity and not quality
- Brainstorm in a group with diverse skill sets e.g. engineering, design, marketing, data analysis, category management, customer support etc.
- No idea is bad idea; avoid discussions and criticism on ideas
Some ideas for our problem
- Vernacular language options in app
- Separate app for tier 3 & 4
- Ordering via phone call
- Live stream from brands/ sellers
- Vernacular voice navigation
- Ordering through kiosk in tier 3 & 4
Defining Guiding Principles
Defining guiding principles helps us to stay focused on our strategy. We (the product managers) will also need to align our stakeholders on these guiding principles.
A couple of key points to keep in mind while defining our guiding principles:
- Mention your core philosophies and strategy for the long term as guiding principles.
- They should act as filters/ guard rails during or post brainstorming.
Meesho being a tech focussed company would want to solve problems at scale using technology while keeping the operations to a bare minimum.
Guiding principles for our problem
- Solve problems with product and tech with zero or minimal operations and related costs: This rules out phone call ordering or kiosk ordering
- Avoid building multiple platforms to control acquisition costs: Rules out a separate app
- Solve the problem without hampering the experience of users from tier 1 & 2 cities: Need to keep new additions compatible for tier 1 & tier 2 users
Prioritisation
With limited resources, we need to create maximum impact as fast as possible. Using guiding principles, we should prioritise the ideas we have left behind after filtering.
We prioritise ideas that have potentially the highest impact and can be executed as fast as possible. A common prioritisation framework used for this is ICE: Impact, Confidence, Effort. The priority score is calculated as (Impact x Confidence)/ Effort
- Impact calculation for an idea is done with guestimation from past learnings and experiments; impact values can be measured on a relative scale from 1 to 5
- Confidence (value between 1 & 5) is a subjective metric to measure the strength of your intuition on the idea
- Add Effort (value between 1 & 5) on the basis of development/ operation effort to execute it
Over time, we have also learnt that products/ features that have a positive impact on other objectives of the company while solving our key problems (projects that can be leveraged by other teams) should be given slightly higher priority. So we add leverage points (1 or 0) as a bonus for such projects.
- Add 1 as leverage point if it impacts other goals in a significant manner
So, Priority Score = [ (Impact x Confidence)/ Effort ] + Leverage
Prioritisation for our problem
After this prioritisation, we know that to solve our user problem, we need to build vernacular language options in our app as the first priority.
Wrapping Up
Using this framework, we can simplify how we make decisions about what to build and what not to build.
At Meesho, we follow this framework for product solutioning whenever we pick up a problem to solve. Decisions which are tough and ambiguous, seem quite straightforward to make with this approach.
As a product manager, you decide what to build and, through effective product solutioning, you can build products that are both useful to your users and business.
There you have it, now we know what to build with more conviction and detail.
