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. As a product discovery coach, I get asked a lot of questions. This makes complete sense—as people read my book, take one of my courses, go through my training, or watch one of my talks, they naturally wonder about applying the concepts of continuous discovery to their own work. They consider the ideas in the context of their own team and company. And sometimes they simply need a little further clarification and guidance in order to feel confident taking the next steps.
But I’ve realized that I often answer these questions in a one-off or closed setting: with coaching clients, during a webinar, or in my Continuous Discovery Habits community. This is helpful to the people who happen to be part of these groups, but it means that not everyone gets access to these answers. And it’s not contributing to my desired impact of increasing the number of product trios who adopt a continuous discovery cadence—at least not at scale.
In order to address this, I’m thrilled to announce a new series on the Product Talk blog, Ask Teresa. In this series, I’ll tackle common recurring questions and topics related to continuous discovery. Have something you’d like me to address in a future edition? Get in touch to let me know!
Question: Who is responsible for different areas of risk within the product trio?
It seems like some areas of risk clearly map to members of the trio—engineers should be responsible for feasibility, designers should be responsible for usability—but other types of risk don’t match up with a particular role.
When building products, we need to ask a lot of questions about the underlying risks and assumptions. Is the product desirable, viable, feasible, usable, and ethical?
I would argue everyone on the team is responsible for all of the areas of risk: desirable, viable, feasible, usable, and ethical. Yes, engineering is going to contribute more to feasibility and product managers might contribute more to viability.
But if you say they are individually responsible, then you end up with competing interests and collaboration becomes impossible.
The trio is jointly responsible for building a desirable, viable, feasible, usable, ethical product.
The product trio is jointly responsible for building a desirable, viable, feasible, usable, ethical product. – Tweet This
This means that the whole team needs to be responsible for all areas. If you say an engineer is responsible for feasibility and a designer is responsible for usability, then what happens when the most usable design isn’t the most feasible? It puts the engineer and the designer at odds. But when both the engineer and the designer are responsible for both, they now have to work together, each contributing their own expertise, to find a usable and feasible solution.
If you say an engineer is responsible for feasibility and a designer is responsible for usability, then what happens when the most usable design isn’t the most feasible? – Tweet This
Responsible vs. Accountable: Is There a Difference?
Every member of the product trio is both responsible and accountable for assessing each type of risk—no matter what their job title.
You might be thinking, okay, so everyone is responsible for all five risks. But what about accountability? Is the designer accountable for usability and the engineer accountable for feasibility? Surely, we should be relying on our individual strengths.
Every member of the product trio is responsible and accountable for assessing each type of risk. I know this can be a hard concept to grasp in our current business context. Most of us work in silos. We’ve never had the experience of truly collaborating. But I do believe that if product trios truly want to collaborate, they have to learn to be responsible and accountable for all of the risks.
I believe that if product trios truly want to collaborate, they have to learn to be responsible and accountable for all of the risks. – Tweet This
That doesn’t mean I’m going to blame the designer if an engineer makes an egregious feasibility mistake. But it does mean I’m going to hold all three accountable if they come up with a solution that isn’t feasible.
When we only hold the engineer accountable, it puts that engineer in a position where they have to prioritize feasibility above everything else. When we each hold our own domains as the most important, all we get are opinion wars. That’s not collaboration.
So while it might make a designer uncomfortable to be responsible and accountable for feasibility, that’s exactly what we want. That discomfort is what motivates that designer to work with the engineer to understand the feasibility trade-offs of different design options. And that’s what leads to true collaboration.
Rely on the Strengths of Each Team Member—But Don’t Overdo It
It’s important to rely on the strengths of each team member, but assigning specific roles can get you into trouble.
What happens when you identify a risk that one team member is particularly suited to address? The team needs to rely on the strengths of each team member. So for example, if they uncover a feasibility risk that the engineer is best suited to investigate, they should let the engineer take the lead on that. But the engineer still needs to communicate back what they learned in a way that helps everyone understand and evaluate the feasibility risk.
Okay, so does that mean the engineer takes the lead on feasibility?
Even in this scenario, I would not call the engineer “the feasibility lead.” When we assign roles like this, it encourages that old silo thinking. It means by default the engineer will take all feasibility risk.
But the engineer isn’t always the best person to follow up on feasibility risk.
Let’s imagine that your engineer is currently dealing with a production emergency and you have a feasibility assumption about the service level agreement for a particular API. Should you wait for your engineer? I wouldn’t. Your product manager or designer could easily investigate this assumption. But most of the time they don’t, because they have a mental model of “the engineer covers feasibility.”
The same is true for many usability assumptions. Both product managers and engineers are more than capable of creating the types of mockups we tend to create for assumption tests. I’m not saying design isn’t a real expertise. It is. But the value of “real design” is rarely needed for an early assumption test. We don’t need pixel-perfect design at this point. So if your designer is busy and a product manager can throw together a quick prototype to get the test live, I want to see that happen.
Don’t Assume You’re Already Doing This
Most teams assume they’re approaching this the right way, but too often that’s not the case.
It’s easy to read something like this and say, “Sure that makes sense. That’s what we do in those situations.” But I’ve seen this too many times to know it’s not true.
When we assign specific responsibilities to different roles, we fall back on those assignments. They start to get ingrained in our brains and we forget to break out of them. So I prefer you actively work to build the model that “We are all responsible and accountable for everything.” And strive to find the balance between relying on the strengths of your teammates and being able to recognize when sometimes going faster is more important than waiting for the strongest person to do the task.
When we assign specific responsibilities to different roles, we fall back on those assignments. They start to get ingrained in our brains and we forget to break out of them. – Tweet This
This question and the subsequent answer was discussed in our CDH Slack community—a space devoted to discussing how to put the continuous discovery habits into practice. You should join us!
