The D-Words of Product
This oversimplified product-making “process” aims to help startups and small teams organize such work in a lightweight way. Product thinking like this isn’t exactly nuclear engineering, but I think it can align, communicate, and coordinate without the complexities of formal product management.
With any “product thinking” process, we’re ultimately trying to tack against the feelings of, “Oh wouldn’t it be cool if …” by tempering them with, “Okay, but wait, does anyone really need this? Is this whole thing just because I’m excited about what might happen if they do? Will people really like this the way I think they will? And if so, are they willing pay for it? And if so, will they pay enough so I can pay my bills … and my investors?”
The answer is a good “value proposition.”
Context, aka “Wait, why are we here again?”
But before all that, as with many things, we should acknowledge the reason why we’re here in the first place.
Maybe we’re part of a startup launching a new product line. Maybe we’re in a large company with an established, proven business model and are leading a new team chartered with building a new tool for our coworkers. Maybe we’re trying to improve an app we’ve written with friends as a side-hustle.
Whatever the reason, let’s make note of it and all the signals as to “why” we are here. Who are the stakeholders? What are their interests and goals? Who is sponsoring our work (giving us resources)? And what are their goals and constraints?
Discover
The first phase of this process entails “discovering” the most valuable customer and user problems, which means embracing a healthy skepticism regarding what we know (or think we know) about their needs.
So from our renewed context, list the people who may benefit from our work. Designers call these abstractions “personas,” and they can refer to consumers, gamers, architects, or even companies.
To make this effective, we should identify more detail than generic professions or demographics. Think of short yet rich descriptions such as:
- “Professional gamers who play team-based multi-player online games for 4+ hours per day.”
- “Casual gamers who only play on mobile phones during their morning and evening commutes and before bedtime.”
- “Occasional gamers who play at their friends’ houses only during social events.”
Such details are quite important.
Signals
Then, we compile the actual “signals” we know already from these personas and, as we say, put each “in discovery.”
A signal is a hint, something that prompts you to ask the question. Maybe a customer said, “It’s really hard to do this in your product.” Maybe a stakeholder said, “I think we should start looking at the market in Asia.” We have to start somewhere, and these are the somewheres.
Here we have our first conundrum.
There are two kinds of signals:
- Feature ideas
- Need ideas
Feature ideas are by far the most common, the most seductive, and the most dangerous. They will easily lead you astray as
Convert features to beliefs about needs.
I like to articulate such beliefs like this:
- “We believe gamers value fast responsiveness (a gain) in their interfaces more than they value other aspects of their experience.”
- “We believe a significant number of graphic designers may find HCI devices like mice and keyboards more of a hinderance to their creativity than a boon (pain).”
- “We believe …”
These belief statements should emphasize the gains, pains, and jobs-to-be-done, not the products, features, or services we might use to address them. Just focus on the challenges faced by your customers and discard everything else.
And at this point, it’s useful to give each belief a short name so you and stakeholders can remember them easily. Whatever tool you’re using, whether whiteboard, sticky notes, or app, write them down separately, in a way you can indicate priority by position.
The worst danger is assuming that customers already desperately want what you want them to want.
Paradoxically, this is really hard to do, and it definitely distinguishes the professionals in the room.
But it’s the core of what product creation is about. What do we believe about our users’ and customers’ behaviors? In particular, think of these beliefs in terms of the gains they’re seeking, pains they’re enduring, and jobs they need to do (i.e. jobs-to-be-done).
And remember, it’s not about you, your ideas, or what you want to be true; it’s about what other people actually need, will use, and will buy.
Seeking the unexpected.
Then, we strategize… How can we seek to learn as much as we can about our beneficiaries? And while it doesn’t always happen, ideally, we want to be surprised by what we find. We want to uncover the unexpected,
Why “discover” and not some other word? Presuming we already know what others need leads to 90% of startups failing, mostly because they build something nobody buys at the price and volume a business needs to thrive. The healthy approach is one of being skeptical of our own knowledge, and thus going about investigating and uncovering what our beneficiaries want.
Often the most effective and unbiased way to do this is to assume we know nothing about our potential customers’ needs, or at least be very skeptical and explicit about our own assumptions.
Again, we’re looking to reveal (discover) valuable problems we can solve for them. If we’re in a commercial setting, we want to solve problems so valuable, so critical, that we
Prioritize
Prioritize them based on an urgency and impact matrix. You’ll have a way of
The task is now to interview customers to validate these beliefs.
Define
Now, we define solutions to the validated and valued problems we’ve identified in the discovery phase. Each gets put to the bottom of the list of features “in definition,”
To do this, I recommend rephrasing every idea as a hypothesis, even if you’re absolutely sure it’s the right thing. Even if you’re right, in this phase of the process, force yourself to do this anyway. Pretend to be a scientist looking at the situation for the first time. What’s the downside? You might miss out on a few minutes of your life just telling yourself what you already know. I’d be that you’re already wasting more time than this.
Assuming that our customers need X,
Design
After the hypotheses are narrowed down, we need to do two things:
Pick the ones we want to test. Work through the details of the design propositions we’re going to build. We draw working mockups We test with users We refine based on user feedback and work out even more details
Develop
Now we build. In the case of apps, designers start making pixel-perfect assets for our engineers. In the case of physical products, we work through the process of building tooling for our beta prototypes.
Deploy
Now we let the engineers deploy their work.