Product Discovery Anti-Patterns, Part 2
Product Discovery Anti-Patterns, Part 2
Welcome back! We round out our discussion of product discovery do's and don'ts by taking a look at how ideas are generated in an organization.
Join the DZone community and get the full member experience.Join For Free
See why over 50,000 companies trust Jira Software to plan, track, release, and report great software faster than ever before. Try the #1 software development tool used by agile teams.
Product Discovery Anti-Patterns: Cargo-Cult Discovery
- Would you use this feature? Your product discovery process equals asking prospective customers what problems they have. (“It’s really hard to design products by focus groups. A lot of times, people don’t know what they want until you show it to them.” The famous Steve Jobs quote that everyone in product design and management has heard of before. The fact is, that it is useless to ask prospective customers in advance what features they would appreciate in a new product. Whether you send questionnaires or you ask them directly in an interview, they will usually fail to imagine both the situation as well as the new product in a way that will provide you with actionable insight. The problem is called “psychological interference” due to the high level of required abstract thinking. Read More: Four Lessons Learned from Making Customer Value Your Priority.)
- Selling non-existent features: What features do you need us to provide to close the deal? Sales managers chase sales objectives by asking prospects for a feature wish-list and provide those to the product delivery organization as requirements. (The problem with customers is that they usually lack the depth of knowledge required to provide useful answers to this question. Most of the time, they also lack the level of abstract thinking necessary to come up with a viable, usable, and feasible solution. As the saying goes: if the only tool you are familiar with is a hammer every problem will look like a nail. Pursuing the sales process in such a way will lead the product into a feature comparison race to the bottom, probably inspired by bonuses and personal agendas. This is the reason why product people like to observe customers in their typical environment using a product to avoid misallocating resources on agenda-driven features. At a systems level, reconsidering individual monetary incentives for salespeople is helpful, too. In a learning organization, teams win, not individuals.)
- What features do you need this year? To be fair, some product managers behave in a similar way to sales when they ask internal customers what features are required. (A call to send in your requirements typically ends up with an epic, Christmas-like wish-list of “requirements.” If the resources of the development team are basically free of charge there is an incentive to grab as much of those as possible by extending the list whether those requests are valuable to the organization or not. You might also observe that stakeholders define requirements that they do not expect to be fulfilled just to gain leverage in future “negotiations” with the product delivery organization. This submission process is normally motivated on the stakeholder side by optimization efforts leading to a local maximum. (Note: Internal stakeholders acting this way behave perfectly rational under such conditions.) Instead, the product delivery organization needs to maximize the outcome of the whole organization. This maximization effort requires entering a competition of ideas across all internal stakeholders to channel resources to the most valuable ideas.)
Product Discovery Anti-Patterns: Ideas, Hypotheses, and Feedback
- #NoTransparency: There is no transparency of how the product delivery organization chooses ideas for the hypotheses shortlist, and how those ideas make it from that shortlist to the experiment backlog. (Establishing the principle that internal stakeholders have to enter a competition of ideas to avoid creating local maxima at the expense of the organization is in itself challenging. The prerequisite for a successful transition to that principle is transparency on the one hand, and a competition watchdog on the other hand. Otherwise, stakeholders might opt out of the process as their efforts appear futile, and rumors might arise: Are HiPPOs driving the selection process? Or will those who shout the loudest be privileged when ideas make it into the backlog of experiments? Do I have to pitch my ideas at 2 a.m. in a bar to the product owner to be heard? Make sure that everyone understands how and why decisions are made. Visualizing both the hypotheses funnel as well as the backlog of experiments has proven to be supportive.)
- No feedback process: There is no process on how the product delivery organization deals with suggestions for new features or other ideas, and feedback is provided randomly at best. (It’s a good idea to have a process that actively involves stakeholders and members of the organization in the product discovery process. People like to have a purpose and to be a part of something larger than themselves. Providing everyone in the organization an opportunity to contribute, without regard to rank, makes working as a product owner easier. Such a process doesn’t require fancy technology—a simple shared spreadsheet or form is enough to get it started. Initially, a template to suggest new product features could consist of questions that address the why, the how, the what, and the for whom. It could address the tactical or strategic nature of the suggestion, a possible time-frame, or an estimate of the expected return on investment. Most importantly, designing a process to handle product ideas should be kept agile: the process should start with a simple solution, and then be improved once initial feedback from stakeholders on the process has been analyzed.)
- Ignoring sales: The sales organization is not effectively included in the hypotheses creation process. (Beware, though, of the tendency of salespeople to demand new features once the quarter is nearing an end to meet sales targets to secure bonuses. This opens the discussion of bonuses is general; a learning organization should not provide individual financial incentives. The possibility of a moral hazard is otherwise too large: using the organization’s resources for free to meet objectives that are personally beneficial is all too human. Do you remember the origins of the financial crisis from 2008?)
- Ignoring customer support: The customer support organization is not adequately included in the hypotheses creation process. (To my experience, cooperating closely with the customer care team is most beneficial for any product delivery organization. Failing to include them is one of the worst product discovery anti-patterns.)
- Hypotheses selection without engineers: The product management team does not include engineers early on in the process of identifying potential hypotheses to test. (Ideas are worth nothing, execution is. Usually, a product delivery organization is flooded with ideas from everywhere: customers, sales, internal stakeholders, HiPPOs, friends, and family—you name it. The most important job of the product people is hence bringing order and transparency to the chaos by establishing a process that turns the long list of ideas and requirements into a short-list. The purpose of this short-list is to run experiments that verify or falsify short-listed ideas as only valuable, usable, and feasible ideas can become a part of the product backlog. To do so, it has proven useful that a triumvirate from product management (business), design, and engineering decides which of the items on the hypotheses shortlist make it into the backlog of experiments. Excluding the engineers from that decision process flaws the whole process from the beginning.)
Product Discovery Anti-Patterns: Egos at Work
- HiPPO-ism: The product discovery process is at least partly driven by the beliefs of individuals of the higher management caste. (This can be best described with the famous quote from Jim Barksdale, the then CEO of Netscape: “If we have data, let’s look at data. If all we have are opinions, let’s go with mine.” Think about it: how does the pay-grade, and hence the individual’s position, in the social hierarchy of the organization qualify that person to have the ‘right’ idea? The Macintosh was a brain-child of Steve Jobs, and he deserved credit for that. He also almost killed it prematurely by refusing to add expansion slots to the design. I do believe that the Macintosh II made the iPhone possible.)
- ‘My budget’ syndrome: Stakeholders do not pitch for development resources but claim that they allocate “their” budget on feature requests as they see fit. (That process leads to the creation of local optima at a silo or departmental level. The effect can be observed particularly in organizations that tie additional benefits to individuals. Instead, resources need to be allocated in the spirit of optimization for the whole organization. Note: ‘Pet projects’ also fall in this category.)
- Sunk cost fallacy: “We have already invested so much. Let’s finish it.” (No matter how much has already been spent, past expenditure does not justify continued work on a product that provides little or no value.)
- Bonus in limbo: We are nearing the end of a quarter. Bonus relevant KPIs (key performance indicators) are at risk of not being met. The responsible entity demands product changes or extensions in the hope that those will spur additional sales. (This behavior is comparable with the ‘what features do you need to close the deal’ anti-pattern, but it's demanded in more pressing fashion, typically four weeks before the end of a bonus period.) Financial incentives to innovate: the organization incentivizes new ideas and suggestions monetarily. (Contributing to the long list of ideas and thus the hypotheses short-list should be intrinsically motived. Any possible personal gain might inflate the number of suggestions without adding value.)
Product Discovery Anti-Patterns: Conclusion
A holistic product discovery and delivery process is at the heart of any learning organization. Filling the product discovery void of the product delivery framework of your choice becomes, therefore, a necessity. And there are plenty of Agile frameworks and methodologies to choose from for that purpose. Watching out for the product discovery anti-patterns listed above will save your organization significant resources in doing so.
What product discovery anti-patterns am I missing? Please share with me in the comments.
The Agile Transition Guide
The latest, 171 pages strong version of “Agile Transition – A Hands-on Manual from the Trenches” is available right here, and it is FREE!
Published at DZone with permission of Stefan Wolpers , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.