Product Discovery Anti-Patterns, Part 1
The Scrum Guide doesn't have a section on product discovery, so it's easy for this process to become a bottleneck. See what one thought leader says can help.
Join the DZone community and get the full member experience.Join For Free
Scrum has proven to be an effective product delivery framework for digital products like applications or apps. However, Scrum is equally suited to building the wrong product efficiently as its Achilles' Heel has always been product discovery. What product discovery part, you may be asking? And this is precisely the point: the product owner miraculously identifies the best way to proceed as a team by gating and prioritizing the product backlog. How that is supposed to happen is nowhere described in the Scrum Guide. Consequently, product discovery anti-patterns emerge.
From sunk costs, HIPPO-ism to my-budget-my-features to self-fulfilling prophecies — learn more about the numerous product discovery anti-patterns that can manifest themselves when you try to fill Scrum’s product discovery void.
Scrum’s Achilles' Heel: Product Discovery
In the attempt to fill Scrum’s product discovery void, product delivery organizations regularly turn to other Agile frameworks like lean UX, jobs-to-be-done, lean startup, design thinking, design sprint—just name a few. The wave of Agile transition projects particularly in large, established organizations over the course of the recent years has provided those frameworks with a tremendous tailwind. Some ideas have, meanwhile, gained buzzword status in the process causing occasional collateral damage along the way (I stopped correcting stakeholders of my current project—mainly from the business side—when they use “MVP” in an incorrect way, for example).
Generally, it is safe to assume that Agile product discovery anti-patterns result from a broader set of issues by comparison to the anti-patterns of a particular framework such as Scrum. (Download for free: The Scrum Anti-Patterns Guide.)
The main contributing variables to various product discovery anti-patterns are:
- Existing organizational dysfunctions. For example, the organization is structured in functional silos.
- A substantial degree of ego issues among individual players—the what-is-in-it-for-me-syndrome—resulting in personal agendas being pursued.
- A complex, multi-layered reporting structure within organizations that filters as well as delays the flow of information, thus impeding communication and decision-making.
Additionally, particularly larger organizations struggle with the necessary transition at the core of the process of becoming an agile, learning organization: the move from allocating budgets to projects staffed with temporary team groups of FTEs to building and funding lasting product teams.
I do believe that a separation between product discovery on the one side (product management), and product delivery (engineering) on the other side is no longer a viable approach. To prevail in today’s game of an accelerated, innovation-based competition — since, as we know, software is eating the world — every organization needs to acquire a holistic understanding of an agile product creation process:
A vision leads to a strategy which (probably) results in a portfolio of products (and services). Each of those products has a product roadmap that needs to be reflected in the product’s backlog, which ultimately provides the Sprint Backlog. This core Agile product creation process is agnostic to the product delivery framework, be it Scrum, XP, or any other framework.
The organization needs to inspect and adapt every layer of this hierarchy continuously within appropriate time intervals. Apparently, there is a difference in the inspect and adapt cadence when strategy and Sprint Backlog are compared to each other. (Example: The Secret Tesla Motors Master Plan (just between you and me) from August 2nd, 2006.)
Keeping this holistic product creation process in mind, you can often observe some of the following product discovery anti-patterns in practice.
Product Discovery Anti-Patterns: The Fallacy of Knowing Better
- ‘We know what to build’: There is no user research, nor any other interactions of the product delivery organization with customers. (There are several reasons causing this phenomenon ranging from a founder or entrepreneur who pursues his or her product vision without engaging in customer discovery activities. Or the product delivery organization is solely briefed indirectly by key account managers. Probably, the sales department deems direct contact of the product people with customers too risky and hence prevents it from happening. What these patterns share is either a bias that is hurting the learning effort or a personal agenda. While the former can be overcome by education, the latter is more difficult to come by as the culprits typically reject the idea that they are guided by selfish motives. For becoming an effective product delivery organization, it is essential that the team directly communicates with customers on a regular basis.)
- Loving the solution: This is a variation of the ‘we know what to build’ syndrome. (There are no ugly children, at least not from their parents’ perspective. This bias seems to apply to products and services, too. Think of Ikea: people value what they created over other products. Which is also the reason that you avoid asking strangers for their opinion: they might not share your conviction. The solution to this product discovery anti-pattern is simple: fall in love with the problem, not your solution.)
- No shared understanding: The product delivery organization does not make any attempt to create a shared understanding among the team and the stakeholders on what to build or why they want to build it. (The best way to secure an engaged and effective communication with internal and external stakeholders is to include them in the product creation process. People care for what they help create. The best way to do so, in my experience, is Jeff Patton’s user story mapping. It is not just a great way to turn ‘requirements’ into feasible user stories at a tactical level. User story mapping is also very well suited to come to an understanding on product roadmap and release planning.)
- Persona-driven, self-fulfilling prophecy: You create the personas first based on what you believe to be the customers or users of our next [add an adjective with a positive connotation here] product or service. (This is a potentially dangerous mental model as you may fall victim to a self-fulfilling prophecy. It is not unlikely that you unconsciously create user tests in a way that will verify your personas in the process. Instead, you should flip the process: first, you observe potential customers in their natural habitat to figure out a problem worth solving. Then you create a prototype addressing that previously identified problem. After the prototype, you create preliminary personas from the insight you gained during the related research. “Preliminary” needs to be stressed, too, as the persona design needs to be constantly calibrated with what you learn while continuously running user tests. There are no static personas. Read More: “Creating Personas.”)
- Annual roadmaps: Product roadmaps are planned once a year for twelve months in advance. (Contrary to popular belief in traditional command and control organizations, product roadmaps are subject to continuous planning. The Agile product delivery process is centered around the idea of working solely on those ideas that provide the highest value to customers and the organization at any given time. To meet that standard, the product roadmap needs to be adapted to learnings gained from running product experiments regularly in an appropriate cadence.)
- The incrementalism trap: You get so focused on improving incrementally that you miss the available innovative leap ahead. Remedy: apply Elon Musk’s first principles thinking model and break down a situation into its elementary pieces to put it back together again in a way that serves your purpose better.
Product Discovery Anti-Patterns: Silos at Work
- Design as a silo: There is a UX/UI design team/department that is organized as a functional silo outside the development team. (UX/UI competence is essential for a lot of cross-functional teams. If those competencies are only available by sourcing them from a different entity, the organization creates an artificial hand-over. The interruption will impede both the speed and quality of the team’s work as crucial information and learnings will only be relayed rather than experienced first hand.)
- User tests/user research as a silo: User tests need to be handed over to a functional silo. The researchers will be reporting back once the results are in. (User tests are an integral and thus continuous part of the product discovery process. Hence, user research shall be run by the team itself by embedding someone with the necessary competencies into the team. Read More: How to Run Lean User Tests.)
- Don’t waste engineers on user tests: The engineers do not participate in user tests because they are deemed too valuable/expensive. (They are supposed to code, as it is easier to hire an additional UX designer by comparison. This is the wrong mental model: the earlier engineers participate in identifying a problem worth solving the better the ROI on their engagement will become as they will bring the technical expertise on feasibility to the table. Building the wrong thing due to isolating the engineers is, for several reasons, incredibly expensive. It is a huge waste of resources, and there will be significant costs of delay—the team could have been built something more valuable in the meantime. Lastly, it is incredibly frustrating to see your effort go to waste, no matter what you were paid to make it. (Read More: (1) Daniel Pink: Drive. (2) In Chapter 2—“The Meaning of Labor”—of his book “The Upside of Irrationality,” Dan Ariely describes an experiment dubbed the ‘Building of Bionicles’ (Paperback edition 2011, pages 66 to 77) where Harvard University students were paid to assemble Lego figures. The experiment aimed at a better understanding of people’s reactions to small reductions in the meaning of their work. His conclusion: “The translation of joy into a willingness to work seems to depend to a large degree on how much meaning we can attribute to our own labor.” (See above, page 74.))
- No engineers or designers working in customer support: Engineers or designers do not work with customer support from time to time. (Have you heard of “support-driven development,” that everyone in a company should spend five percent of his or her time in customer support? This is not a new idea, and a lot of successful companies practice it to simplify the flow of information from a client’s problem to its solution. It proves to be an effective way to discover pain points and create products that clients love. Kayak.com co-founder Paul English: “Customers are a big source of my e-mails. Anytime anyone contacts us with a question, whether it’s by e-mail or telephone, they get a personal reply. The engineers and I handle customer support. When I tell people that, they look at me like I’m smoking crack. They say, 'Why would you pay an engineer $150,000 to answer phones when you could pay someone in Arizona $8 an hour?' If you make the engineers answer e-mails and phone calls from the customers, the second or third time they get the same question, they’ll actually stop what they’re doing and fix the code. Then we don’t have those questions anymore.” Read More: Everyone on Support.)
- A sole source of truth: The product delivery organization relies solely on either quantitative or qualitative feedback. (You need to take both sources into account to come to an informed decision. Data does not provide any information on ‘why’ things are happening. Data only addresses ‘what’ is happening. At the same time, focusing exclusively on qualitative feedback may make you vulnerable to bias and unfavorable mental models. The road to self-fulfilling prophecies is paved with good intentions.)
Come back tomorrow to see the rest of this great list of anti-patterns!
Published at DZone with permission of Stefan Wolpers, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.