Have you heard? My new book Continuous Discovery Habits is now available. Get the product trio's guide to a structured and sustainable approach to continuous discovery. “How do we know if we are building the right things?”
“We are building feature after feature but to what end?”
“How do we know what customers really want or need?”
Have you heard these sentiments before? I am hearing them more and more.
Underlying each quote is a yearning to do more discovery work.
Marty Cagan makes a great distinction between discovery and delivery.
Discovery is the work that product managers do to figure out what to build.
Delivery is the work that product managers do to deliver a product.
Some teams split these roles into product mangers who focus on discovery and product owners who focus on delivery. I like that model. But not everyone has that luxury.
Delivery Eats Time for Discovery
When the same person is responsible for both discovery and delivery, discovery is often left undone. – Tweet This
Many companies view product development from the perspective of throughput in a factory. A product manger’s primary job is to keep engineers busy.
The problem with this model is that product managers tend to spend the majority of their time working with their engineering teams on getting product out the door.
They spend their days grooming backlogs, prioritizing bugs, answering questions, and simplifying requirements in response to schedule slips.
These are all important tasks, but when they fill your day, it means that you aren’t spending time talking with customers, understanding needs, observing challenges, and uncovering pain points.
It means that you don’t have the context to know whether or not you are making good product decisions.
It leaves you and your team left asking the questions we opened with.
Don’t Start By Adding Discovery
It can be easy to recommend to teams mired in delivery to start doing discovery. But this doesn’t work.
You already know that you should be doing more discovery. The challenge is figuring out how to add it to your busy day.
You need a systematic approach to discovery that is sustainable. – Tweet This
A usability study here and there is better than nothing, but it’s not a discovery strategy.
Neither is talking to customers here and there.
Nor is combing through your feedback emails or your GetSatisfaction / UserVoice feeds.
A systematic, sustainable discovery strategy requires time.
Fix Delivery Challenges to Free Up Time for Discovery
That time has to come from somewhere.
Companies have two choices. They can either put the halt on delivery to free up time for discovery or they can relieve their product managers of the burden of delivery.
While I know more than a few companies who are getting very little out of their delivery efforts – either they are building the wrong things or their throughput is very slow – I know of none who are willing to halt delivery all together to free up time for discovery.
So this leaves us with our second option.
If you want to free up time for discovery, you have to lessen the burden of delivery on your product managers. – Tweet This
Now I’m not suggesting that product managers shouldn’t play a role in delivery. They absolutely should.
However, product managers should not be the only ones responsible for delivery outcomes.
Product development teams need to share the responsibility for delivery.
This means everyone from your tech leads to your designers to your data analysts need to feel responsible for shipping product.
This may sound obvious, but it rarely happens in practice.
Product managers interact with the rest of the business. They shield the rest of the team from the consequences of missed schedules.
This can be a good thing. But when taken too far, it means that the rest of the team doesn’t share in the responsibility. Over the next few weeks we’ll explore how to find the right balance.
Don’t miss the next post, subscribe to the Product Talk mailing list.
Excellent. The solution to doing discovery activities isn’t just to say it shall be so. You have to make room for the change.
The caveat is that, in a sense, delivery is a key part of discovery. We deliver on a set of hypotheses and an experiment so we can learn.
But the entire product team is often responsible for the delivery. Product managers are (or should be) more focused on empowering the team with the market insights derived from the discovery and learning activities.
Roger, I agree. Delivery is a part of discovery – but only if the team is setup to test hypotheses and has the metrics they need to evaluate results.
Great post Teresa where you have described the situation I am facing with my team for a long time, with no solution so far: the product managers can not act as product managers because their role as product owners takes all their time.
Hi Eva, I’m working with a couple of teams facing the same challenge. In the coming weeks, I’ll be sharing how we are shifting the responsibility of delivery to the entire product development team and creating time and space for discovery work. Stay tuned.
Good insight. Sorry but I tend to disagree (unless I have understood it incorrectly) that usability surveys, talking to customers and going through feedback emails would not help. We have got tremendous amount of great feedback which has helped us to make new discoveries about the product and continuously refine it.
I am guessing you would be covering more about “A systematic, sustainable discovery strategy requires time” in your subsequent posts. That might clear up things 🙂
Hi Milind, You are right. You can gain great insight from usability surveys, talking to customers, and going through feedback emails. I’m not suggesting that you not do those things or that they are not helpful. In fact, quite the opposite. I argue instead that you can’t do these activities just every once in awhile. You need to do them continuously. That’s what takes time and thus requires that you not spend most of your day focused on delivery challenges.
Great post as always thanks Teresa. Totally agree it requies a change in habit to ensure it’s long lasting – same reason almost all diets fail!
One small thing, you have a typo in “I know of none who are willing to halt delivery all together to free up time for delivery.”.
Thanks again
Tim
Thanks, Tim. Typo fixed. And yes, the diets analogy is perfect.
I totally agree Teresa – so many of the teams I work with really struggle to find the time to focus on the discovery side. It is a real catch 22 situation – the engineers want them available to their teams 24/7 but these same engineers also get huge benefits from the insight that customer discovery brings and it does ultimately help them to create better products. I think the answer is in educating the delivery teams to take more responsibility in the development process and not to rely on the Product Manager as much as they do – cutting back on the number of agile meetings that the product manager attends can help hugely. The product manager though does need to remember that they are predominantly there to articulate the “what” and the “why” – engineering are the “how” – too many product managers get too embedded in the “how” side of things.
Yup, I’ll be writing more on how to do exactly that (“educating the delivery teams to take more responsibility in the development process”) in the coming weeks.
It seems like some companies are devoting an entire team to this when they create a customer success team. What are your thoughts on having a customer success team and working with them to outline some of the discovery that needs to take place from the product side?
I think it’s great that companies are investing in customer success teams. But that doesn’t replace product discovery. If your product managers, designers, and engineers aren’t involved in discovery you lose out on their expertise. We can no longer according to silos and functions. We have to learn to work as cross-functional teams.