A map of discovery methods that any product manager should master
Everybody must have heard about “discovery” today. People frame it in so many ways. I personally prefer Marty Cagan’s framing, but it doesn’t need to be the only framing. The main idea is simple and straightforward: you need to build a product that’s viable (for the business), valuable (for the user), usable (by the user) and feasible (from an engineering point of view). I’ve written here a longer article about “why” discovery is important.
I intended this article to be the list of those discovery methodologies that I personally consider applicable by anyone, not an exhaustive list. Just consider it as your product discovery Swiss knife. I am deep diving into each of these methodologies with richer details — where possible, I am including links to these new articles.
So, let’s dive straight into it.
Understanding your market
I am writing a more detailed article here, but in short you will need to understand your competitors, companies with similar profile, newly funded start-ups or newly launched products.
While many don’t consider this as part of their discovery journey, I can say that for me it is the first mandatory step when framing a product. You can argue that this is more business than product, but product is also business at the end of the day.
Understanding your customers
This is the most sensible and important topic. If you want to build a great product, you will need to understand the motivations, frustrations, pain points, and anxieties of your customers. You will want to understand what makes them happy and what makes them sad, what excites them about a product, about their pricing sensitivity, about their day to day schedules and or about how they gain trust in brands and products.
In general, you will not have to cover all these topics (you won’t have to do this), but you will need to choose the most important learnings about your customers and build your solutions accordingly. I will be covering this topic in one of the next articles, but for now here’s a short overview of the methods that will help you in uncovering your customers:
- Qual research— I can’t stress this enough: this is the most important tool in this case. There are several well known methods for pursuing user interviews (like Jobs to be Done — JTBD approach) for uncovering your customers — in this case their motivations, but the main point is that you will need to start talking to them, actively and empathetically listen to them. Eventually magic will happen. Here’s my overview of the most important qual research methods for a product manager.
- Surveys — when you already have hypotheses about your customers’ behaviours, you can rely your research on surveys as well. But you need to have these hypotheses first, because it is infinitely harder to unpack, for instance motivations, via surveys or even verbatim comments that it is through user interviews. More thoughts about surveying as a product manager here.
- Verbatim comments analysis — this can be a great source for forming hypotheses. If you already have verbatim feedback, label it and use it to form hypotheses. Furthermore, you can even use some NLP models (even unsupervised) to group the verbatim feedback in clusters based on similarity. I am describing here a way to approach it.
- Observations, journal keeping and other.
Obs: There are other methods out there and my user research colleagues will probably say that I am being superficial for not treating valid user research techniques the same way as I am mentioning other methods. The reality is that I, as a product person, have my own preferences — and usually choose those methods that are simpler and faster. When you can afford an army of user researchers, then the method is less important — you have a professional team to lean on. As a product person who doesn’t work in a large corporation, you will not have the luxury to relay on user researchers or anthropologists, instead you will need to pick up methods that help you become efficient and make valuable decisions.
Ideation — Hypotheses forming
This will be the next step after you understand your users, their motivations, their pain-points and anxieties or aha moments.
This step is important because it forces you to think critically and challenge your newly formed vision of the world.
You should have already formed your list of problems that you want to solve. Now it’s time to rank them and start hypothesising solutions.
Ideally you would do this in a room with other people (at least your “best friends” — the designer and the tech lead). Next you will get into sketching solutions (similarly to how design sprints work)
Solution validation
This is mostly about understanding, usability and value. In the previous phase, you started designing solutions. Now it’s time to validate them. The main outcome of this phase is the following — do people understand your solution, are they able to use it and will it solve their problems?
You usually do this through 1:1 user interviews: you come up with a prototype (it can be anything from paper prototypes to POCs). You just need to ask the right questions — asn I’ll get back with a special post on validating your solution.
Engineering feasibility validation
This part is about understanding what’s feasible, what can be done short term and what can be done long term. It will help you design your MVP.
In an ideal world, the Technical Lead was present in all the previous sessions. Hence the TL will know everything about the customer problems, the hypotheses and the solutions.
In reality this doesn’t happen as frequently as it should be, so you will probably end up having some refinement sessions with the entire team or some conversations with the TL.
Either way, at the end of this you should have a decent idea on how to phase out your MVP and what gets on the team’s backlog.
I am writing here about how to involve your Technical Lead into the product discovery process.
Experimenting
I am also including in Discovery various experimenting experimenting methods, because I truly believe that discovery goes beyond qualitative methods or technical feasibility.
In short, experimenting is about launching the hypothesised and validated solutions as some sort of an experiment: if you have traffic, you can run an A/B/C… test.
You can even gather more feedback and confidence BEFORE building a solution by launching various honey-potting initiatives (“Coming Soon” landing pages etc). It all depends on the purpose and the capabilities of your solution.
I’ve written here a more detailed article about experimenting.
However, if you are confident that your solution will work, the best way to proceed further is to just launch it (maybe with a slow rollout).
There are lots of other approaches and frameworks to help with discovery and, while I hate frameworks and prefer to customise the approach to what fits the company culture, I will mention “User Story Mapping” as one of the discovery approaches that I love.
You can place it after you understand your customers and you can frame it as brainstorming/ideating about solutions for larger products/systems.
So, as mentioned in the beginning, this is not an exhaustive list of methods to approach discovery, but you can consider it as a Swiss knife when you start practicing discovery in your company.
