No matter what we do at Whispir, we want to make sure we’re building the right things — but truthfully, you never know if something will work until it makes the first contact with customers. If you ask people in the industry, people will say 70% of your ideas will probably fail, and of the ones that work, they will require 3–4 iterations before they start delivering significant value.
So if you’re not iterating over things you’ve already shipped, you’ll likely end up with a product that is not helping customers effectively. So how do you know when an idea is good enough to start building given all the uncertainty?
At Whispir, to work out if ideas are worth pursuing, they must meet four basic needs, and the discovery of these four is one of the three core promises the product management roles at Whispir commit to. Within my department (which includes Product Marketing, UX, and a Product Intelligence / Strategy function), each role has 3 promises which are listed in confluence clear for everyone in the company to see. I found this was a simple way to communicate to the business what is in a job description without them having to read too much. They are TLDR job descriptions, essentially.
For us, our ideas must be viable, desirable, feasible, and easily made usable.
So let's say you have a few ideas on the table. To learn if these ideas are viable, desirable, feasible, and usable, we (about 80% of the time at least) push the ideas through 5 phases, 4 of which make up our continuous discovery track, each with its own demands and bits of information we are looking for. Very few things are mandatory, but I prefer for the teams to work in somewhat of a consistent way and this is more a work in progress than something we do exceptionally well today.
As the discovery track unfolds, it moves into the delivery world, which is where we (sometimes) prepare 3 things.
- A product candidate sheet: PCS (which contains all the research, allowing product leaders to review ideas and showcase the material that talks to the why we should do something. Doing it in a formal way allows us to scale the product function in a consistent manner and ensure our discovery practice looked somewhat predictable and consistent across teams as we grew)
- A product requirements document: PRD (Sometimes, if the teams feel it works best for them, they might write a single source of truth requirements document that contains some detail about the build. Not everyone does this truthfully, and I think that's fine. But for more complex ideas, some teams find this useful. Some people just chuck it all in JIRA as stories and that works okay.)
- Jira cards — Which by this point, everyone knows what they are for.
Where do ideas start?
All our ideas start with observations — not instincts. Starting your process from observation is something I took away from IDEO, a company that really influenced the way I think about design. I got exposed to all this stuff from Scott Tong, who sent me down a path to learning the IDEO way. It became clear that all their books, their ideas, courses, and their practices seem to start with getting out in the field and actually observing what is happening using a handful of learning personas you can adopt. Their approach (Which is documented in a great book called the Ten Faces of Innovation) is to take on the traits of these learning personas and learn what is actually going on in the world. There are ten personas all up, broken into three groups, but the learning personas are The Anthropologist, the Experimenter, and the Cross-pollinator (my favorite).
This is why we start our process with observation. By looking at what a customer is doing, what they're experiencing, and learning about their world, our ideas are more informed, generally better supported by the business, more insightful, creative and innovative, and often, more interesting to work on.
5 Phases of good ideas
- First, we make some observations about what the hell is going on.
- Next, we speculate on some ideas that might help.
- Then, we research those ideas, looking for reasons to say no, market information, finding out if customers even like our ideas.
- Next, we run experiments to try and prove our ideas will work.
- And finally, if all looks good, we try and productionise (is that a real word?) the idea and get it into customers' hands.
- In an ideal situation, once you have it in production, you go back to observation and learn what's happening. Do people like it? Is it working? Is it delivering the value we thought it would?
The building phase is where all the requirements are defined, so it's not just the building but also the preparation of the build. Now in practice, this shouldn’t be a waterfall phased approach — I probably need to spell that out. You should feel empowered going from experiments back to research or even going from experiments back to speculation. You want the freedom to let the evidence guide your path rather than just following the process forward.
When there is a belief that an idea meets those 4 criteria, it gets considered for prioritization as part of our planning cycles, but usually not before. We typically don’t prioritize ideas we know nothing about (although if I’m real about it, it happens way more than I’d like).
But it’s small…can’t we just build it?
Sometimes we just know we have to do something, and it doesn’t require this kind of rigor of going through the 5 phases. As an outsider looking into the technology and design function, it’s tempting to think everything can just go straight to the building phase because we’re in a rush. This is because the uninitiated, quite frankly, are often impatient and willing to roll the dice more than the product teams usually are. After all, if the idea doesn’t work, nobody is more devastated than the teams that build it. The stakeholders are usually long gone by then.
When you're running your whole operation from either ego or instinct, that’s dangerous, and if you are brave enough, you should step back and have the product & design function educate the business more broadly on how continuous discovery leads to better outcomes for customers. One option, if you have the cash, Marty Cagan, the high priest of product management runs courses for really senior executive teams to solve this very problem and get them up to speed on making room for discovery and experimentation, so as a last resort, this may help greatly if you’re struggling to sell the idea to your leaders.
But if you want a rule of thumb, roughly 20% of the work we build fits this straight-to-build shortcut, and these ideas are often known as ‘table stakes’ concepts. I’ve also noticed, they tend to find their way to the top left of the JTBD maps as well, so if you want a visualization, that’s normally where they appear (the jobs, not the features obviously).
This 20% of ideas are usually things every competitor will have and customers are usually happy with it, so sometimes your hands are tied. It might not be the most exciting work — but it’s essential to making your product work for customers.
To know if a feature should go through all 5 phases or which ones go straight to building, I tell people it is best to check with one of the product managers directly as there is a lot of grey to this — but we’ve notionally settled on the following criteria to help because I couldn’t just say “…I dunno, it just depends on the vibe?”. So, things might go straight to the building if;
- We have to do it, even if we don’t want to. (ie. There is some compliance or regulatory thing going on — a security issue perhaps)
- The absence of it means churn will be over 80% and we can prove that somehow. This might be some kind of obvious friction in the onboarding process and support and CSM functions are screaming about it.
- It’s embarrassing.
- It’s faster to build it than to test it.
Impatience is not one of the reasons.
So when do we pull the trigger and book the work?
In the end, once we’re convinced the idea meets the desirability, viability, feasibility, and usability thresholds, which to be clear, we are really specific about, we evaluate the work as part of our impact vs complexity matrix, which informs (not decides) which ideas might be worth pursuing.
Essentially, we try to find work that is low in complexity, but high in terms of getting us towards our goals.
