Guest Post by: Daphne Garcin (Mentee, Session 9, The Product Mentor) [Paired with Mentor, Chris Butler]
So we want to innovate and create new features for our product. But where do we start? First let’s ask ourselves what we want to achieve. Which change in users’ behaviour do we want to drive? Which business outcomes are most important for us strategically? When are these outcomes not met?
In other words, we start with the problems that we want to solve. Then we think about potential solutions or features. We do this because it is difficult to predict whether a feature will indeed help us meet a particular outcome. The trick is to make a hypothesis for each of these features on whether they will drive a particular outcome. Hypotheses are only useful if we test them (with customers), to validate or discard them.
As a team who decides to research which new features to develop, we first want to define our business outcomes and key results (OKR), together with our problem statement.
As an example, our problem statement could be:
- Customers encounter a series of friction points when embarking on a shopping journey in a large supermarket. With our product, we want to make shopping in store easiest. As shoppers use our product, this helps us to drive less operational costs.
- Today we are not meeting the level of usage that we expect for our product.
- How can we better communicate about our product’s benefits and how can we improve our product so that it further brings ease to shopping, thereby driving a higher usage and less operational costs (e.g. payroll)?
From this, our business outcomes are to increase usage by making shopping easiest with our product, and to decrease operational costs. We will also want to go more granular on the metrics / key results that we will use. That way, we can break down our outcome into different indicators to measure success.
The high-level direction (e.g. focus on cutting costs or on increasing revenue) should reflect the wider strategic direction of the company or department. If the wider strategy is unclear, high-level outcomes should be discussed with leadership first. The conversation then continues within the team to more accurately define our outcomes to go for.
It is very important to reflect upon who to involve. Indeed the relevant decision-makers, influencers and domain experts should be involved, informed and consulted, as appropriate.
Once our outcomes are clear, we want to better understand: what are the current obstacles to progress against our outcomes? Obstacles are often linked to the pain points that customers currently experience [here in their shopping journey]. We also want to think in terms of customers’ gains or customers’ needs: whether they are unmet or whether they could be met significantly better. By better meeting customers’ needs, we expect to drive our outcomes forward.
Ultimately we aim to come up with different problems to solve. We we will then prioritise them depending upon how much of an opportunity we think each problem is. More on this below.
The problems to solve: customer impact and business impact
We can learn about which problems to solve for our users, i.e. our users’ pain points and needs, from different sources: customers’ observation and interviews (research), customers’ feedback (existing surveys, social media), domain experts, cross-functional conversations, past initiatives and importantly quantitative data.
In our above example, let’s focus on the outcome: ‘grow usage by making it easiest to shop with our product’. We may learn from interviews that customers find it unclear as to why they would use our product. Or we may indeed observe that we are not explaining our proposition anywhere in stores or through any marketing. So the lack of visibility and of communication on our product’s benefits would be a pain point.
From observing and interviewing shoppers, we may also note that remembering all required items is a real need, which requires some effort to solve and which is met to a certain extent.
When it comes to prioritising, I find it handy to use two factors to estimate the expected value from solving our problems: customer impact and business impact. The highest the customer impact and the more it aligns to our most important business outcome, the better. Customer impact should take precedence.
It also makes sense to consider the level of effort we think is associated with solving a problem: for two problems with a not so different impact, we would indeed favour a low effort problem over a high effort one.
Adding that when we think about which problem to solve, it is beneficial to extend our thinking beyond outcomes and to think of the overall company’s strategy:
- Where does our company fit in today’s market?
- In tomorrow’s market?
- How does it relate to our product?
- Today our company may focus on price sensitivity, but is this trend growing in five years time?
- What other trends may we want to position our product along?
- What about the environmental-friendly aspect, food quality, the health-conscious?
It is also important to learn from our customers about: what are other ways customers use to solve this problem without our product? Why would users go for our product?
For example, we mentioned the need to remember the grocery items we need. Customers solve this problem in very different ways. Some use a shopping list, usually on paper, some have everything in their mind, some tend to always follow the same itinerary in store, thereby remembering what to buy. Others, still, give a call to their partner to double-check. And some will use a combination of these.
So how well are customers meeting this need currently? Does it vary according to behaviours?
Because we will most certainly be missing some data to make a clear call, decisions need to be agreed collaboratively at team-level. What is important is to start somewhere! What may help is to think about how we can test our assumptions. That is when prototypes will enter the scene and become our best friends.
The solutions: validating our hypotheses with prototypes
Now that we have agreed on different problems to go for, we want to come up with testable hypotheses as to how to solve these problems. And we want to test these hypotheses with customers. This is core to our experimentation.
Our goal is to gain insights on which opportunity to pursue first in development: where is there most value to expect for customers and against our business metrics? What can we learn about our biggest risks and how to mitigate them? Risks may lie within the actual value of the solution: is it indeed desirable for the customer? And if it is, is it desirable in a way that is viable for the business? The feasibility risk may be looked at further down the line, as early as when more development is required. Regulations and, for many products, privacy can also be a risk to keep in mind: are customers ok providing their personal information? Is it legal to use their data in the way we aim to do?
At this stage, we would like the group to come up with ideas. One way to frame the conversation to enable this is:
we explain the process again, from what we want to achieve to how we create hypotheses, we also share examples of ideas. Ultimately we want to foster a non-judgmental and accepting environment for the group to contribute with their knowledge, their ideas and to free up their creativity.
Here let’s take the example of a painful on-boarding / signup process.
One example hypothesis may be: if we make customer identification quicker, we expect a higher signup rate and a higher repeat rate.
We can then brainstorm ways to identify customers from the simplest to the most tech-savvy ways. Brainstorming can be done as a collective conversation or individually, ‘dumping’ ideas on post-it notes. Sketching can make for a more visual approach. In any case, we always want to keep in mind the problem from a customer’s perspective.
One example idea may be to identify customers at the beginning of their shopping trip from their payment card. We may discuss the extended reach this may have, the potential customers’ concern on security and privacy.
Next we absolutely want to test our hypotheses with customers.
We can start with user interviews and mockups to validate high-level direction i.e. concepts. For example, before going about nice prototypes, we may ask customers whether they would be after getting this or that kind of information during their shopping trip and at which stage of the trip. We may use very simplified mock-ups first, then refine the functionality with more testing.
Finally and ideally we aim to put functional (or seemingly functional) prototypes in the hands of customers.
The appeal is that the more realistic the prototype, the more we may learn from customers theoretically. We may even get closer to collecting quantitative data.
Yet the more functional the prototype, the more effort we need to develop it.
We certainly want to limit our development efforts at this stage, i.e. before we commit to building a proof of concept. So let’s stick to thinking about testable tools that require little, fast development or no development work at all.
On our ‘lack of communication on benefits’ example, we may think of a way to explain our proposition better in a store versus not doing anything different in a control store for two weeks, then measure any difference in signups. We may even do that through signs before changing anything in the software behind screen displays.
In a different example, we dealt with constraints by starting with interviews, then brought concepts to life through simple mockups. We scripted a scenario for customers to follow (e.g which items to buy). Although scripts have limitations, they help us make our mockup useable in practice.
There are different techniques to enhance mockups with minimal effort, when we don’t have a functional prototype. A common one is the concierge approach, where the hypothesised function is performed manually / behind the scene as opposed to coded into a software solution.
Finally one important point is about how confident we can be about our experimentation. We tend to be biased towards what we believe in. We may hence think about how to test opposite arguments. As mentioned above, it is crucial to tackle what constitutes our biggest risks value-wise and usability-wise.
If we take the customer’s need ‘help me remember the items I need to buy’, would customers really turn to our product for further information if the way they use our product at present is purely to go through their shopping journey as quickly as possible? What are the opportunities / moments in the journey to allow for information sharing? Would it be any useful to notify customers about items they may have forgotten if they are already at the till?
We may also put the problem in the context of our next customer problems: can a functionality that helps customers remember items be enhanced with a different functionality? That tells customers where their desired items are? Else?
Conclusion
Innovation does not come randomly. Some methodologies, such as the one presented here, are available to help. It is always about understanding which problem(s) we want to solve for our users or potential users of interest.
Starting with user research, we continue with experimentation: based on hypotheses and ideas, brought to life through prototypes, which we put in the hands of our customers.
So innovation starts and ends with our users, their needs and our measurable business outcomes.
If this part of the work may often remains qualitative, it will give direction for development to validate our path quantitatively. That way, we can approach development and then delivery on more solid grounds: having minimised our main risks and gained confidence on the value we are creating for our users and our business.
Daphne is passionate about her craft: collaboratively coming up with solutions to users’ needs. Her product management experience spans sectors such as retail and travel. She is a French, soon also a Brit. Eternally curious, Daphne’s interests extend to how we create communities (or not) in big cities.
More About The Product Mentor
The Product Mentor is a program designed to pair Product Management Mentors and Mentees around the World, across all industries, from start-up to enterprise, guided by the fundamental goals…
Better Decisions. Better Products. Better Product People.
Each Session of the program runs for 6 months with paired individuals…
- Conducting regular 1-on-1 mentor-mentee chats
- Sharing experiences with the larger Product community
- Participating in live-streamed product management lessons and Q&A
- Mentors and Mentees sharing their product management knowledge with the broader community
Sign up to be a Mentor today & join an elite group of product management leaders!
Check out the Mentors & Enjoy!
Jeremy Horn
The Product Guy
The Product Guy 