Product Discovery - Who & When
Product Discovery - Who & When
Creating the Habit of Continuous Discovery With The Right People Involved
Insights often come when we don’t expect them.
It’s often when we connect many seemingly unrelated pieces of information that we come to the most profound realizations. That’s why some of our best thinking is done in moments of calm, like driving or in the shower (and why it’s important to take time to think).
In one company where I was working as a product manager, I was doing regular customer interviews. We were walking through a process, when the user made an offhanded comment about a different feature of our product. Apparently, they really didn’t care about that feature as part of their workflow. But we cared about it. And had been spending a lot of time on it recently. So I had to dive in deeper. While it was important to our business, and to the security of our product, our users really didn’t care about it. It was an extra step they had to wait on. I was surprised because we hadn’t considered that it wouldn’t be important.
It wasn’t an insight we were looking for (we probably should have been in hindsight), but we found out useful information because we were continuously looking anyway. That’s the point. We should always be looking, talking, noticing, because we never know when the right idea will come along.
When To Do Product Discovery
When should we do product discovery? My simple answer is that we should always include discovery work as part of our process.
As long as software has existed, we’ve been doing some form of “discovery” to understand what we should develop and send to users.
When software was packaged into boxes and shipped to stores once a year, this process of discovery looked much different than it does today, at least in theory. Product teams would have to get all the requirements for the software well before the shipping deadline. Anything that the customers would want or need for that year would have to be included because you’d only get one shot to put it on a CD or DVD and ship it to them, so there was an emphasis on detailed requirements and long lists.
But that is not how we deliver software any more. And it’s not how we should do discovery either. While that may seem intuitive, I’ve repeatedly seen teams and organizations that still rely on lengthy product requirements documents to hand to engineering teams as if they were going to package up a DVD and ship it before tax season.
Dual Track Development and Continuous Discovery
With modern product development and modern product teams, we have largely moved away from the need to ship once a year or once every six months (though I realize that’s not the case everywhere, and I send my sincere condolences).
With that comes the need to shorten our discovery cycles, making them work continuously with our development cycles. This should make sense. If we were releasing software once per year, our discovery may take 4 months followed by 6 months of development and 2 months to prepare and release. If we shortened that cycle to every 6 months, then we’d need to shorten our discovery to a month or two. Keep shortening the window of delivery, and we’d keep shortening the overall cycle like in the image.
In the past, discovery and development were typically separated. But now they can run in tandem, and should run together as we are continuously doing user research and product discovery as a product team (product managers, UX designers and engineers) while also developing and releasing small increments of our product to users. This way we are continuously learning, continuously improving and continuously launching.
Who To Involve in Product Discovery
A VP of engineering recently asked me who I thought should be involved in product discovery. The answer can vary from company to company depending on team and structure. But at its core, we should always have our product manager, UX designer, and engineering lead involved in our ongoing product discovery and research. If you’re fortunate enough to have dedicated user researcher as well, then you’d want them involved too.
It may also be good to periodically expand this core group and involve others. That may include additional members of the development team for their insight, members of your sales team or client management team, members of your marketing team, and other key stakeholders as needed. Depending on the area you’re working in, partners in each of these groups may offer key insights in your discovery process. I’ve found outstanding success adding people from our support groups or other areas when we are doing discovery (interviews, discussions, etc) directly relating to their area of expertise.
Finally, it may occasionally be good to invite senior leaders to some of your product discovery sessions. I’ve had mixed success with this. Some senior leaders are very interested in seeing and hearing what users have to say while others don’t have time for it. Often the best thing to do is to package what you learn into bite-size chunks and summarize so you can inform everyone and give a sample of what you’re learning without involving executives in the full sausage making.
Splitting Discovery and Delivery
Splitting discovery and delivery is a question that seems to come up fairly frequently. I was in an AMA (ask me anything) recently with Marty Cagan and several people asked him about splitting up discovery and delivery work. If you’re familiar with Marty’s philosophy or writing, you’ll know he’s very much opposed to this idea, and he said as much. I echo that sentiment.
I’ll write more about this topic later, but splitting discovery and delivery work is a bad idea. I’ve seen it fail firsthand many times. It may feel exciting to be on the discovery side of that equation. Think of the innovation labs at companies or the product managers pitching their big ideas on the next significant innovation. But then how well do those things get transferred over? How well do teams execute on something they’ve had no part in until they are given all the requirements and told to build someone else’s idea? It rarely turns out well. And it doesn’t leave anyone satisfied. The best scenario is empowering teams to find solutions and letting them own that work end-to-end, discovery to delivery.
The best product discovery is done continuously, as we incorporate questioning and understanding into our regular process. That is how we gain insight we would have otherwise missed.
And ensuring we have our teams involved from the start means we have the right perspectives all along the way. No single person can come up with all the ideas that are going to lead to success.
Best of the Rest
Netflix vs Hulu: A Breakdown of the Product Experience (podcast) - We look at the difference in the product experience between these two apps and how things like thumb zones, settings, and engagement impact the overall design.
Innovation vs Imitation (podcast) - I’m a big fan of getting down to first principles and building from there. They cover that, and many other topics, in this podcast. It’s worth a listen.
2020 Bundles - Stratechery (article) - This is an interesting take on the different bundling and unbundling services, and what there purposes are. Each is different. It gets me thinking how each of our products may approach our markets differently, even if we’re competing in the same space.