as aproduct discoverycoach, i get asked a lot of questions. this makes complete sense—as people readmy book, take one ofmy courses, go throughmy training, or watch one of my talks, they naturally wonder about applying the concepts ofcontinuous discoveryto 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: withcoachingclients, during awebinar, or in mycontinuous 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 tomy desired impactof increasing the number ofproduct trioswho 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 瑞士vs喀麦隆水位分析 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?2022世界杯吧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.
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.
thetriois 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?
you might be thinking, okay, so everyone is responsible for all five risks. but what aboutaccountability? is the designer accountable for usability and the engineer accountable for feasibility? surely, we should be relying on our individual strengths.
every member of theproduct triois responsibleandaccountable 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 areopinion 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
what happens when you identifya riskthat 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 feasibilityassumptionabout 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 aquick prototypeto get the test live, i want to see that happen.
don’t assume you’re already doing this
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!