Meet Sally and Pam. Sally is a product manager, Pam a user experience designer, and they are working on a new mobile app.
They’ve conducted customer interviews, defined their MVP, and are now working through the initial designs.
Even though their MVP will only include a fraction of their near-term vision, Pam wants two weeks to work through the design of the near-term vision, as she’s worried if they build piece by piece, they’ll end up with a Frankenstein user experience. She wants to get feedback on the near-term designs before they start building the MVP.
Sally is anxious to get the MVP out the door as soon as possible and wants Pam to focus on those designs first.
How should they proceed?
Pam is right to be worried about the overall user experience. We’ve all been frustrated by products that feel like features have been cobbled together.
Sally is also right. They should be focused on getting their MVP out the door as quickly as possible. Taking two weeks to design feels too long, especially when the majority of the work won’t impact the MVP.
The Key Assumption That We Think Saves Time But Actually Wastes It
To resolve this conflict, we need to expose a key assumption at play here.
Pam is assuming that the near-term vision is mostly right. She wants to ensure that the design of the MVP is coherent with the design of the near-term vision. She doesn’t want to design A, without knowing how A will fit with B, C, and D.
This approach would be effective if we were confident that A, B, C, and D were the exact right things to build. We don’t want to design A in isolation, without considering B, C, and D. Otherwise when we get to B, we’ll need to redesign A, and when we get to C, we’ll need to redesign A and B. This would be very inefficient.
However, if we assume that our near-term vision and our MVP are mostly wrong, then Pam’s approach doesn’t save us time. Instead, we are doing two weeks of design work that will likely be wasted.
Even though decision making research suggests that we should be prepared to be wrong, it’s actually quite hard to do this in practice. Our egos get in the way. It feels like we are right and so we proceed as if we are.
Decision-making research shows that we should be prepared to be wrong, but our egos get in the way so we proceed as if we are right. – Tweet This
But when teams instrument their products and honestly track the impact of their product changes, we see that we are wrong more often than not, even when we feel like we are right.
So if instead, we assume that we will get A wrong, or at least parts of A wrong, and that when we get to B, we’ll likely need several iterations to get B right, and so on, then taking two weeks upfront to design our near-term vision no longer makes sense.
If we assume we are likely to be wrong, Sally’s argument to get the MVP out as quickly as possible makes more sense.
The Value of Inefficient Iterations
But we also can’t ignore Pam’s concern. We do need to care about the overall user experience. This is why we iterate.
If our near-term vision includes A, B, C, and D, presumably we picked A as our MVP because it’s at the heart of the value that we intend to offer. If A doesn’t work as we expect, it puts B, C, and D at risk.
This means that we can safely ignore B, C, and D, while we work to get A right. Sally is right to focus on getting the MVP out as quickly as possible.
However, after we get A right, and we start working on B, our goal isn’t to ship B as quickly as possible. This is what leads to cobbled together designs.
At this point, our goal is to get A and B to work well together. That means we might have to change the design of A. And that’s okay.
This might feel inefficient, but it’s only inefficient when you get everything right the first time. This will rarely happen.
In the instances where we get at least some of the details wrong, this approach will be faster.
Don’t believe me? Let’s look at an example.
Suppose Pam spends two weeks designing A, B, C, and D. After launching the MVP of A, they iterate based on what they learned, and A morphs into something that no longer needs B, but instead needs E and also changes the way C needs to work.
Pam spends another two weeks cutting out the design of B, adding E, and iterating on C to reflect what they learned.
After the launch of A and E, they learn that E isn’t quite right, further impacting C. Pam spends a week iterating on A, E, and C.
You can imagine how this continues. Pam has to redesign everything each time they learn something new.
If instead Pam only designs A, she runs the risk of having to redesign A when she adds B. But here’s the key difference: While working through the options for how to make A work, she’s learned a lot about what users need from A, so she has a wealth of knowledge to draw from when modifying A to work with B.
In the previous scenario, where Pam is redesigning A, B, C, and D together, she hasn’t learned anything about A, B, C, and D yet, so her designs are guesses at best.
While Pam will still have to go through many iterations to get A, B, C, and D to work well together, each iteration is informed by the prior one. This leads to shorter cycles and faster overall design.
When each product iteration is informed by the prior one, it leads to shorter cycles and faster overall design. – Tweet This
This is counterintuitive. Let’s look at why.
Most Teams Adopt a Validation Mindset
Like Pam, we tend to use customer interactions to validate our ideas. We believe it’s our job to design the solution and the customer’s job to sign off that it works for them.
As a result, we tend to wait until we are all done with the design before we get feedback from our customers. We expect our customers to validate that we got it right.
There are several problems with this validation mindset.
First, we get feedback too late in the process. Most product teams design just ahead of their engineers’ delivery cycle. What they are validating needs to go into next week’s sprint. If it doesn’t work for the customer, the team doesn’t have time to fix it. Even if it does work, but the customer has ideas for improvement (which they always do), we rarely have time to integrate them.
When we validate our ideas, rather than co-creating with customers, we get customer feedback too late in the process to integrate it into our product. – Tweet This
Second, because of the escalation of commitment and confirmation bias, we are far less likely to act on our customer’s feedback even when we do have time.
As a refresher, the escalation of commitment is the cognitive bias where the more time and energy we invest in an idea, the more committed we become to it. If we do all of the work to design A, B, C, and D, we become committed to that design. Even those of us who have every intent to hear and integrate customer feedback will struggle with this.
And thanks to confirmation bias, the bias where we are twice as likely to hear confirming evidence than disconfirming evidence, we will miss most of the feedback from our customers that our idea isn’t working quite as we intended.
This is why we often see that even when we interview customers and usability test our ideas, we still find that our ideas didn’t have the intended impact when we release them.
This doesn’t mean that we should skip the interviews or the usability tests; it means we need to get better at both of these activities to work around our biases. (See my courses on customer interviewing and rapid prototyping.)
We need to get better at customer interviews and usability tests in order to work around our biases. – Tweet This
It also means we need to drop our validation mindset and adopt a co-creation mindset.
Why Co-Creating With Customers is the Answer
A validation mindset stems from the belief that we know best when it comes to technology. And that is true. But our customers know best when it comes to their own needs.
We know best when it comes to technology expertise, but our customers know best when it comes to their own needs. – Tweet This
Now some of you might be thinking of Steve Jobs who argued that customers don’t know what they want or that no one would have known to ask for the first iPhone. So let’s be clear on this distinction.
Customers don’t know what technology can do. They would have never asked for the iPhone because they didn’t know the iPhone was possible. However, they did know that they hated checking their voice mail, that texting using numbers was incredibly painful, and that small screens made it hard to find the contact you wanted to call.
Apple applied their technology expertise to solve these problems and many more with the first iPhone. There’s no way they could have done that without learning that these were important problems in the first place.
Successful products are the result of technology expertise applied to real customer needs. Co-creating with customers allows you to ensure that you are building something that your customers want or need.
Successful products are the result of technology expertise applied to real customer needs. – Tweet This
So what does co-creating look like?
Unlock the Power of Co-Creating Solutions
We make product decisions every week, therefore we need to engage with our customers every week. Many teams struggle with this. They argue that they they can’t turn around designs fast enough to engage with customers every week. But this is a validation mindset creeping back in.
We can’t finish production ready designs every week, but we can and should be iterating on last week’s work. If we drop our validation mindset and adopt a co-creation mindset, we can get feedback from our customers while we are still in the messy middle of iterating on our design.
Instead of asking our customers, “Does this design work?” when we get to a final design that we are happy with, we can show our customers three or four design ideas that we are playing with. We can ask them, “What do you think of these options?”
This subtle shift addresses both of the problems we identified above and has two added benefits.
First, we are getting feedback from our customers much earlier in the design process. It’s much easier to iterate on sketches and wireframes than to iterate on production-ready designs. So when our customers give us feedback, we are much more likely to integrate it.
Second, we are less prone to escalation of commitment and confirmation bias, because we have invested less time into each idea. We are also exploring a compare and contrast decision rather than a whether or not decision, which is going to help guard against confirmation bias.
In addition to solving our two problems, we also get two added benefits.
The first added benefit is that when we share less-polished designs, and especially when we share multiple options, our customers are much more likely to give us honest feedback. It’s clear to them that we are still designing and they will be less concerned with hurting our feelings.
And the second benefit is that they will be more likely to jump in and share new options that we didn’t consider. Now some designers might fear that this will lead to “design by committee.” You don’t have to use your customers’ options. But you will learn a lot about their needs from the options that they suggest—and that is priceless.
How can you shift your mindset from validation to co-creation? If you are interested in practicing your co-creation skills, check out my Rapid Prototyping course.
Dave Snowden is researching a similar, but more extreme idea. They give a piece of work to a team. They work on that for [timebox], and give their result w/o further comment to team B and so forth.
Teresa Torres says
Help me connect the dots. How is that similar?
Sascha A. Carlin (itst) says
“Related” is the better term, sorry.
Their co-creation is handed around the globe to some back to the original team after 24 hours. The process is sequential, and here lies its beauty: You validate an artefact without any explanation or knowledge about who worked on it.
This goes a long way to avoid validation mindset.
Kevin Cornwall says
You lost me. Why would there ever be a 2-week, design/develop,/release timeline for any new product?
Still, co-creating with customers doesn’t solve the initial problem of not having an overall vision. Customer’s will also be wrong.
Teresa Torres says
Thanks for taking the time to read and reply. Maybe I can help clarify.
The two weeks referred to in the article is not a design / develop / release timeline. In the scenario described, the designer is asking for two weeks to design only. The assumption behind this ask is, we need time to understand the holistic design upfront. And the assumption behind that assumption is that we can know upfront what the holistic design should be before getting input from customers.
It’s that trail of assumptions that I’m questioning in the article. Co-creating iteratively does solve this problem because it wipes away the assumption that we can envision the holistic design upfront.
As for whether the iterations are design iterations or design and build iterations depends on the nature of the product. Plenty of iterations can happen in just the design phase (as it seems like you are suggesting).
Chris Nunes (@ucnunes) says
This is a great breakdown of deeper efficiencies in prototyping. So, co-creating with the customer is involving the customer in the origination hypothesis, not just having the customer validate our own product hypotheses? It’s kind of like directly connecting a call between the customer and the product, rather than playing operator and relaying the product message? I think some teams might fear that they simply become a mechanical turk/vendor in the build process, rather than a solution architect. But I think the team/architect in this scenario is actually steering the customer in for a soft landing on their expectations vs the actual deliverables, while having them side by side for the whole process so that there is no failed delivery of vision and there is sign-off on everything. Better for contract fulfillment, if not end product.
Teresa Torres says
I like your operator analogy. The key here is that the customer isn’t creating the solution on their own. The team still brings plenty of expertise on what is possible and they need to be hands-on in the solution creation process. But we need to the voice of the customer present and a part of that process.
Shaun Austin says
Really like this article! I think a broad theme that can be taken away, which I have seen over and over from multiple groups (Leadership, Product, Engineering, UX, etc.) is that we need to collaborate early and often. It seems to be human nature to have the mindset of “tell me what you need, let me go off on my own and do it, and then we’ll gather again to review when I’ve completed it”
Would love to see a mindset shift across Product development teams to be more willing to collaborate from the very beginning. Not only should UX be sharing ideas with customers early and often, but Engineers should also be a part of and see those interactions, rather than being of the mindset of tell me what to build and I’ll go off and code it.
Teresa Torres says
Yes, I take it for granted that product managers, designers, and engineers are working together on discovery that I often forget to mention it. But it’s all three of these groups who should be co-creating together with customers, not just the designer or not just the product manager.
Damon Valenzona says
Hi Teresa! At what point would you say engineers get involved in this? Are they a part of the input into ‘A’ in the ABCD example? Will they work closely with design and product to talk about the capabilities of technology and the rough levels of effort when comparing different solutions?
I love the ideas of pushing people to assume they are wrong more and having a rough understanding of the road ahead but knowing it is very likely to change because we are very likely wrong :).
Teresa Torres says
Yes, I want to see the engineers involved as early as possible. Ideally, at the point where we are forming the product vision and definitely when we are starting to generate ideas.
Justin Williams says
First – kudos to you. Product Talk is IMO one of the few must read product sites. I don’t know how many times I’ve re-read your customer interview mistakes article. 🙂
The first part of this post though was a bit confusing to me (I love the second part about Parallel Design).
Since taking Marty’s class I’ve thought of MVP not as the first, minimal version of your product but as the quickest, fastest way to test a product hypothesis – i.e., the fastest way to find out if you should build the product in the first place.
If this is true then it seems like the above decision should depend on what the team is trying to learn.
For example if you are the early AirBnB team, the critical thing to learn would be: is there any demand for this crazy new product (renting an air mattress on a stranger’s floor). Designing an entire flow is a waste of time until you validate that there is demand. So a Landing Page test might be in order.
But if you are early Zappos – you know there is demand to buy shoes online but there are specific objections that you have to overcome. So in the Zappos case, you would want the designer to think holistically about getting the user through the flow and allying their objections.
Interested to hear your thoughts!
Teresa Torres says
Thanks for the kind words.
As for your thoughts on MVPs and your two scenarios, I completely agree. I’ll try to layer each example onto the story I told.
In the AirBnB example, the product manager is saying let’s get a landing page test live and the designer is saying, we need to show screenshots of the product on the landing page and I don’t want to show screenshots that are inconsistent with our short-term vision. This is a bit of a silly example, because few designers would make this argument.
The Zappos case maps a little better. The risk isn’t will people buy shoes online, it’s will they buy shoes online from us. So the product manager wants to launch a bare minimum site that allows the team to test will people buy shoes online from us. The designer in my example would be arguing, we can do that, but I don’t want to have to redesign the entire site next week when we decide to add features B, C and D. This is where the designer might ask for two weeks to design the short-term vision. This is also where I argue a validation mindset is creeping in and the designer is better off redesigning with each iteration rather than designing upfront.
Does that help?
Justin Williams says
Ah yesss. Got it, and agreed. Thank you for the reply. Keep up the great work! 🙂
Junaid Ahmed (@superjunaid) says
Excellent write up in defining a successful product iteration feedback road map. As this is close to how enterprise applications are going towards. My team works very closely with our business counterparts as defining the solution with the teams expertise, what I really like in this example is the additional transparency afforded by connecting the business with the solutions available to them.
Love this. The image on smarter iterations is very compelling. I think I’m a little confused on one point though. In saying co-creation speeds up feedback, if the constraint is releasing, we can, as you say, validate ideas with rapid prototyping, with or without co-creation, right? Maybe the message is more “JITJER”–just in time design coupled with just enough research?
Teresa Torres says
An iteration is not necessarily a release. An iteration could be an iteration on a prototype. The key is to get feedback early and often on prototypes (co-creating) and not prototype the whole solution and only get feedback when we are ready (validation).
Makes sense. Thanks! Love your stuff btw.
Andrei Gonzales (@andreigdesign) says
I love this, except for the “applying technology expertise”, particularly citing Apple as an example. If anything, I think it’s more appropriate to say they “applied DESIGN expertise”.
Teresa Torres says
In this case, I’m using “technology expertise” inclusively. I mean product, design, and engineering expertise. Product teams bring their knowledge of technology, of what’s possible, of how it should work, to the table, while customers bring their own needs / context to the table.
I really liked this article.
Do you have any tips for B2B cases where a 2-weeks checkpoint (co-creation/validation) is not always the usual case? what would be your recommendation? (In this particular case, I’m talking about a software product that can be installed on customer premises, not a SaaS product)
In practical terms, would you try to identify early on one/many customers that would be committed enough to attend sprint demos for instance?
Teresa Torres says
For on-prem software, I would try to identify some nearby customers where you can regularly spend time with them on site.