Wavelengths of Product Discovery and Delivery
While working on an internal document on the progress that we’ve been making in moving towards continuous product discovery, I came across The Place of UX by Ryan Singer of Basecamp. A thing he wrote in the comments stood out to me in particular:
[W]hen we work on entirely new products … [it’s better to have] a small intensely collaborative pool who figures everything out together.
As I am currently working on a product that is more or less entirely new, this comment was immediately relevant to me. But initially, I took this comment as an advocacy for letting everybody on a small team working on a new product figure everything out. With the dual tracks of product discovery and product delivery on a product team now accepted knowledge, at least to my understanding, this sounded a lot like running a single-track team. But let’s back it up a bit.
Product Discovery Projects
For the most part of our existence, we’ve been developing software in 2-week sprint cycles. It is still in part our delivery modus operandi. Right before sprint kickoff, specs that PMs had come up with were broken down into tasks by senior engineers. They were estimated and we‘d make sure to leave enough time for overhead and overly optimistic estimates.
The specs that us PMs would come up with were always at minimum informed by talking to our customer success or sales teams. They knew our customers best, we thought, and would thus be able to make accurate predictions about what they would or would not like.
In addition, we did acknowledge that we needed facetime with actual customers. I remember a quarter where we especially felt this urge. One of our OKRs was therefore to “interview 15 customers”. We created an extensive questionnaire, asked various internal departments for input on what to ask and in the end had something like a four page document. Then, we sent out emails asking customers for time to hop on a call. In total, I can remember three (nonetheless very insightful) interviews. To my knowledge, we failed to draw any far-reaching implications from these on how to build better products.
In general, things were not working as expected. Features estimated to take two sprints ended up taking five or six. Features, even for internal tools, were not being adopted. Despite training the teams that used our software again and again, they simply did not get it.
Duality of Discovery and Delivery
During a 5-month parental leave I took after my son was born last September, I spent countless hours watching product management talks and reading blogs. To keep a clear mind, I eventually zeroed in on a few people that I decided would be the “source of truth” for me in terms of good product work going forward. These people include Kathy Sierra, Marty Cagan, Ryan Singer, Bob Moesta, Teresa Torres, Janna Bastow, Des Traynor, Tom Chi and a few more.
In the end, I thought I had a refined mental model of what good product teams worked like:
- Work in two streams of (continuous) Discovery and Delivery. (Marty Cagan)
- Validate ideas in Discovery, not Delivery, and adopt tools that help you learn what you need to know quicker. (Teresa Torres, Tom Chi)
- Focus on outcomes, not output. (Teresa)
- Focus on the progress that customers are trying to make in their live, i.e. the “job they hire your product to do”. (Bob Moesta & Chris Spiek, Intercom, Basecamp)
- Think about the Post-UX UX! (Kathy Sierra)
- Work collaboratively – e.g. involving engineering in Discovery – and empower teams to work within variable scope. (Marty, Ryan Singer)
- Acknowledge the uncertainty in the work and roadmap accordingly (i.e. no GANTT charts of the next 12 months’ output) (Janna Bastow)
Since coming back to work in February this year, I’ve been lucky to have the backing of our CPO and CTO in trying a new process that involves weekly facetime with customers, validating ideas with prototypes and working in a small and empowered team in longer cycles – a process that is more inline with the above ideas.
A Theory of Discovery and Delivery Wavelengths
So, let’s jump back to the intro. Should you break up the duality of discovery and delivery when working on an entirely new product? Should you go into single track mode?
I’ve spent quite some time thinking about this and ended up with a concept to describe (at least to myself) why you should not. There will still be people who’s day job is discovery, even in such projects. They’ll be speaking with customers, creating prototypes and running user tests. And there will also be people who’s day job is delivery. They’ll likely lay the plumbing for the new app, put the first infrastructure in place and tackle the technical project setup. But the frequency of interaction between those people is likely to be higher!
If you think of the two work streams of delivery and discovery as intertwined, they start looking like waves.
And ultimately, the wavelength of the discovery-delivery-streams should be a lot shorter when working on a new versus a matured product!
That very much resonates with the brief experience I’ve had as I started to work on a more or less completely new product with a new process and a new team setup when I came back to work in February. We are a small team of a product designer (50% of his time), three engineers and me as PM that are working on revamping the buyer experience on store2be.com – a marketplace for live marketing locations.
But enough theory. Let’s draw this out.
Here’s the original slide I have in mind when thinking about the two discovery and delivery work streams:
And this is what it could look like in wave form, for a typical, matured product, and a team working Scrum-style 2-week-sprints:
This is what Basecamp’s 6-week-cycles would probably look like using this visualization, including 2 weeks of cool down between projects:
And lastly, here’s what our last project’s setup looked like — the discovery stream starting with a 4-week lead time, technical setup taking about 2 weeks, and then going into a highly integrated discovery and delivery mode:
As for a “theory”, one could formulate something along the lines of “the wavelength of discovery and delivery work streams should be aligned with the novelty of the product you are building. It should be shorter, i.e. measured in days, when novelty is high, and longer, i.e. measures in weeks, when maturity is high”.
To me, this metaphor of thinking of discovery and delivery as two waves that move together and intersect in more or less regular intervals has felt immediately useful in describing different modes of working on a product team. It can also help teams reflect on “are we running at the right wavelength for where our product is at and what we’re trying to do here?” I will keep it in mind in the coming months.
I am very curious to hear what you think! How does any of this reflect your experience? Do you find the concept of wavelengths in this case helpful?