TL;DR: Webinar Product Discovery Anti-Patterns — April 10th, 2018
Scrum has proven to be a practical product delivery framework for digital products like applications or apps. However, Scrum is equally suited to build the wrong product efficiently as its Achilles heel has always been the product discovery part. What product discovery part, you may think now. 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 is. How that is supposed to happen is nowhere described in the Scrum Guide. Consequently, when everyone is for himself, product discovery anti-patterns emerge. I believe it is time to address this issue with the webinar product discovery anti-patterns.
From sunk costs, HIPPO-ism, 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.
🗞 Shall I notify you about articles like this one? Awesome! You can sign up here for the ‘Food for Agile Thought’ newsletter and join 30,000-plus other subscribers.
Join more than 120 peers from May 27-29, 2021, for the Virtual Agile Camp Berlin 2021, a live virtual Barcamp using open space technology principles and practices.
Update: The Replay of the Webinar Product Discovery Anti-Patterns Is on Youtube Available
The video of the webinar is now on Youtube available:
Note: If the browser will not start the video automatically, click here to watch the replay of the webinar product discovery anti-patterns directly on Youtube.
Cannot see the subscription form?
Please click here
Update: The Slide Deck of the Webinar Product Discovery Anti-Patterns Is Available
The slide deck of the webinar is on Slideshare available:
If the slide deck will not work within this browser window, please click here and check all Hands-on Agile webinar slide decks directly on Slideshare. There, you will also be able to download a PDF of the webinar product discovery anti-patterns.
📖 Book Recommendations for the Webinar Product Discovery Anti-Patterns
There are two books I recommend reading:
- Daniel Kahneman: Thinking, Fast and Slow. (Note: This is an Amazon affiliate link.)
- Dan Ariely: Predictably Irrational, Revised: The Hidden Forces That Shape Our Decisions. (Note: This is an Amazon affiliate link.)
📅 Upcoming Webinars
Download your invitations now — there are no more than 100 seats available:
- May 22nd, 2018: Webinar #4: Agile Failure Patterns 2.0
Note: All webinars are aired from 06:00 to 07:00 PM CEST. (That is 12:00 to 01:00 PM EDT or 09:00 to 10:00 AM PDT.)
📺 Subscribe to Age of Product’s Brand-New Youtube Channel
Now available on the Age of Product Youtube channel:
- Hands-on Agile Webinar #3 on product backlog anti-patterns.
✋ Do Not Miss Out: Join the 3,300-plus Strong ‘Hands-on Agile’ Slack Team
I invite you to join the “Hands-on Agile” Slack team and enjoy the benefits of a fast-growing, vibrant community of agile practitioners from around the world.
If you like to join now all you have to do now is provide your credentials via this Google form, and I will sign you up. By the way, it’s free.
Webinar Product Discovery — Related Articles
Download the ’Scrum Anti-Patterns Guide’ for Free
Transcript Webinar Product Discovery Anti-Patterns (Edited)
Hello, everybody. Welcome to the first Hands-On Agile Webinar. I'm your host Stefan Wolpers, and today we will be talking about product discovery anti-patterns. The webinar will take about 20 minutes, and after that, there will be sufficient time for a Q&A. Some background on my person, I've been working the last 12 years as an agile coach, scrum master and product owner mostly in fast-growing, venture-capital funded startups, or at the moment I'm working for a large utility here in Germany.
Now, I reached out a few months ago to the community. I was pitching them about the idea that Scrum, given it's the most popular form of agile product development at the moment and it's often equated with being agile, is lacking a product discovery process. Interestingly, the prevailing response was that there is no product discovery in Scrum, which I believe is exactly the issue I'm trying to point out. Garbage in, garbage out, and I'm my experience scrum is perfectly suited to build something no one is interested in. In the end, everything comes down to this one mystical creature — the product owner.
If we look at the scrum guide, the product owner is the sole and accountable person who's responsible for optimizing the value of the work of the engineers. So, the product owner either has ideas or at least identifies ideas or curates suitable ideas from wherever, and then validates whether those ideas are product backlog worthy or not. Interestingly, the scrum guide also states that the product owner may outsource this kind of work to the development team, which I believe is not really helpful to understand the crucial role of the product owner in the Scrum process, particularly on the management side. In my experience, this approach turns the product owner role in the Achilles heel of the whole process. Even worse, if you remove the product element as an independent and respected role, for example, you are sticking to your organization's stage-gate process, scrum easily mutates into some quite effective waterfall 2.0 process.
Now, before we go on, let me introduce you to my holistic perspective of agile product development in the post-industrial world. So, my mental model starts with a vision on the left side, and you end with delivering code continuously to a resilient system on the right side. I labeled the part on the left side product discovery and the part at the right-side product delivery. Of course, the separation is not as strict. Usually, the two parts overlap somewhere in the middle of the near-term planning, or in Scrum speak and the product backlog area. As far as product discovery is concerned, it tends to be significantly more affordable and low-tech on the left side, and much more expensive if you move over to the right side. It's literally comparing a napkin to a full-blown continually delivery pipeline.
So, from a risk mitigation point of view, the further to the left the product discovery happens, the better for the organization. Most of the people agree with this basic concept of how this product creation process works, and how product discovery fits into it. However, applying these basics, in reality, turns out to be completely different. There are anti-patterns all over the place, and those happen in startups as well as established organizations like General Electric. In my experience, there are three main categories for product discovery anti-patterns: systemic issues, personal issues, and psychological issues. To make things worse, those patterns can overlap in several categories.
Okay, let's start with my dirty dozen of product discovery anti-patterns, and the first category is systemic issues, particularly those of legacy organizations, which are usually featured by functional silos, a rigid budgeting process, and hierarchies. All of those provide fertile ground for product discovery anti-patterns.
The first one basically everyone knows, it 'my budget, my feature.' Think Jira monkeys and coders. The product department is more treated as an internal agency, and stakeholders pursue the, "we pay for you," approach. Instead of naming the problem and asking the product team to find a solution for that, they come with a solution they believe is the right way to handle this. This is particularly often happening in organizations that focused on the shareholder value approach in the 1990's and outsourced, for example, software development as a non-core feature, or a non-core asset of the whole organization. Too bad to say it with Marc Andreessen that, "software is now eating the world."
This anti-pattern very often leads to something that is called Conway's laws; you're basically shipping the org chart as the communication structures are incorporated into your product. Very often this results in local optimization efforts within a siloed organization.
Number two, speaking of silos, for example, marketing or sales, insist on channeling communication with customers and users. Their salespeople are preventing [the product team] from talking directly with customers, which is making user interviews and user research very problematic because you always have some kind of hand over this, always some kind of non-direct communication. Mostly this happens because the two different silos here have completely different mental models. Where the engineers and the product people want to talk to the customers to understand what their actual challenges and problems are, sales is more concerned with maybe losing a customer because the engineers might say something that the customer does not like.
Number three, coders code. Engineers are supposed to deliver code and nothing else. They are not supposed to, for example, talk to customers, very often under the label that coders are too expensive and too scarce and they shouldn't waste time talking to customers. I believe this is pure Taylorism at work. It's entirely output oriented. The problem is, well, we're no longer assembling Model T's, but we go every day somewhere where no one else has gone before. Rule of thumb is that coding is less than 30% of the whole product creation effort, and the best way to increase the productivity of the product team is to avoid building unnecessary stuff, features that no one is using, and it is essential for that purpose that the engineers talk to customers.
Number four, okay, as a product team we shouldn't assume a victim role here. We also contribute in some form or another to this whole product discovery anti-pattern process. For example, there's one issue that regularly triggers frustration on the side of the stakeholders if we are not transparent about how we work. Our suggestions, ideas, requirements can actually make it into a sprint and be produced. This black box approach reduces stakeholders' willingness to collaborate across the board, thus impeding our product discovery efforts.
Next category: personal issues. So, personal agendas, I don't think we have to talk about it in detail.
Pet projects: pet projects are stakeholder-driven. However, they do not exclusively apply to middle management. You can also think of gold plating as an engineering approach, or why an exotic new technology suddenly becomes a part of the tech stack. A root-cause analysis will probably point to the "what is in it for me?" syndrome with one or more stakeholders. It could be, for example, the optimization effort for the next career step, or the person in question is building something he or she is proud of, which makes it more valuable to them. That's the IKEA effect. Pet projects, in my experience, are always driven by personal intent. This is not necessarily malicious, but there's always something personal about it. The residing high-personal investments can lead to the blame game in case of failure, death marches, or other face-saving techniques at the expense of the organization and the product discovery process.
Number six, HiPPOism. HiPPO stands for the highest-paid person's opinion, and there's the famous quote of Jim Barksdale of Netscape, "If we have data, let's go with the data. If all we have are opinions, let's go with mine." However, there's no scientific proof that the pay grade of an individual is linked to his or her ability to identify what's worth building. Innovation is nowadays a team sport and the lonesome innovator is a myth, right? Yet, submission to the will of the one with the higher status is often very common, maybe except for Google probably.
Number seven, bonus at risk: the misalignment between individual incentives on the one side and the team objective on the other side. Shortly before the end of the bonus period, the product team gets swamped with must-have requirements from sales. Typical manifestations are that they sell specific features to close contracts without talking to the product [team] before. Or, more desperate, they are making assumptions that certain new features will bring new business. You know, you throw something at the wall to see what sticks. This certainly is not a way you would like to see product discovery handled.
Psychological issues, the third and most interesting category of product discovery anti-patterns.
The sunk cost fallacy, number eight. We believe that we make rational decisions most of the time. In fact, we're often only rationalizing them afterward. So, one mind shake is the sum-cost fallacy. Here our loss aversion, "Gee, we already invested so much. We're almost there. Just let's push for the last 5%," overrides the rational decision. For example, to cut losses.
I do not know whether you are also tuning into the soap opera called Berlin's new airport from time to time? Okay, being a Berliner, this is something personal. However, it's a good example of this sunk cost fallacy. I mean, they started planning that thing from 1991 on. They started construction in 2006, and 2011 was the supposed grand opening. Did not work to massive violations of safety standards, and we still don't have a clue when the airport is going to open. Probably in 2020. No one knows. It's not just about the ballooning costs, but no one has answered the question of why we're not taking a different approach: you know, cut losses, tear this thing down and rebuild it. It could be faster and less expensive.
At this point, I'd like to point to two really good books that you should read. It's one, Daniel Kahneman's Thinking Fast and Slow, and Dan Ariely's Predictably Irrational. I will link to them in the show notes.
Substitution, number nine. Another piece from Kahneman's book. Kahneman's system number one tends to deliver answers to most of the questions that come to your mind very quickly. Now, for example, consider the question, "How's your life nowadays," which would require you to reflect and analyze. That's actually another part of your brain. Yet, you come up with an answer immediately. The trick here is that the brain's actually not answering this complicated question, but it's answering a related question. For example, "How was your mood today?" and takes this substitute question as the ground for the belief that you answered the original question.
The issue that we have here, you may come across this in the form of, "Do we know what we have to build?" The problem with this is that the people are not just simply loving their solution to the problem, they also believe that they are answering the right questions. Hence, their engagements and they're pushing for their solution to be built.
Validating your solution: This self-fulfilling prophecy is closely related to the "I know what we have to build" issue we just talked about. With the best intentions, you want to validate your hypothesis and solution, you are data-driven, right? However, your confirmation bias lets you unconsciously pick a design that will deliver exactly the data you need to confirm your solution by a so-called self-fulfilling prophecy. The tricky thing is you will not notice it. It really happens unconsciously to you, and you will only be able to analyze this in hindsight.
This happened twice to me over the years. First as a chemistry student in the lab. At least that [occurrence] resulted in a good discussion with my professor of organic chemistry at the time. And a few years ago, I was creating an application called Ebookmakr that allowed you to simply create e-books online, and in that case, we picked the wrong participants for our user tests who absolutely confirmed what we suggested. So, that was a bit more frustrating experience.
Survivorship bias, number 11. Survivorship bias or survival bias is the logical error of concentrating on the people or things that made it in the past through some selection process, and overlook at the same time what didn't happen, typically because of a lack of visibility. Let me tell you a story. This is really much simpler than it sounds. During WW2 the then U.S. Army Air Force wanted to improve the survival rate of their planes, so they ran a large analysis of returning planes, and they meticulously figured out all the damages the planes received. They came up with an idea of where to put additional armor, for example. So, you see the red dots here that are symbolizing bullet holes and other battle damage.
It took a Hungarian mathematician to point them to the fallacy that they were going through because they were focusing on those who made it back to base. They thought, "okay, maybe we should improve the armor of the parts that were damaged," and he said rightfully, "No, you should put the armor in the places where actually you can't see battle damage because those planes didn't make it back," and this is precisely what they ended up doing. So, they added the protection in those parts of the planes that didn't show battle damage.
This is a very common pattern that we also see in product management because data-driven survivorship bias is here also an issue. If you look at your funnels and where you create new users, where you managed to turn people […] into paying users, and then at the end, you come up with people who are giving you feedback. If someone visits your website you have a bit of data, maybe someone joins a free trial, and you have some data, but the only real data is provided by paying customers.
Now, if you intend to grow your user base, maybe you shouldn't focus on the tons of data that you have available because those people are already paying you. You know, much more interesting would be to go further to the left side. Start at the beginning of the funnel and understand better why people are not reacting to your marketing campaign, or why website visitors are not signing up for the product. [Ignoring these parts of the funnel] is a typical application of the survivorship bias fallacy that we see here.
The last one, number 12: psychological distance. Steve Jobs once said, "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." Psychologists call this effect psychological distance. It's very hard for other people to walk in your shoes, which is also the reason for asking users what they need is usually completely overburdening them. They will probably have no clue what you're asking from them because they don't see it, and even if there is a problem, they probably will most likely not find the right way of framing it. Remember the old saying, "If your only tool is a hammer, every problem looks like a nail." This is also the reason why product teams always ask the stakeholders to come with a problem to them and not with the presumed solution, like "I want a link or a button."
There's also another issue. At the same time, if you, for example, run user interviews and ask your users for help, they want to help you. Reciprocity is deeply embedded in our social DNA. Imagine you invite someone for a user interview: You provide them with attention. You listen to them. You're interested in their experience. You provide them with coffee or something to eat. Of course, they want to pay you back, and the moment you ask them a question, and you ask for their help they want to help you, and they will come up with something that probably is not even a problem just to reciprocate your kind offering and the attention you gave to them. So, be cautious. Only money talks.
So, those were my 12 product discovery anti-patterns. I hope you considered this webinar product discovery anti-patterns useful, and I also hope that you will now understand why diversity in a team is not just a top HR topic at the time, but also crucial if you want to avoid those patterns. I'd also like to make you aware of the next webinar in two week's time on April 24. We will then be talking about agile maturity and the agility assessment framework. Last but not least, if you like to reach out to me, just email me at stefan@age-of-product.com. Age-of-product.com is also on the blog. We have a great newsletter with more than 17,000 subscribers, and one of the largest Slack groups of agile peers. We have two different Twitter accounts: @StefanW and @AgeOfProduct. Thanks a lot for your patience, and let's start with the Q&A now.
📅 Scrum Training Classes, Workshops, and Events
You can secure your seat for Scrum training classes, workshops, and meetups directly by following the corresponding link in the table below:
See all upcoming classes here.
You can book your seat for the training directly by following the corresponding links to the ticket shop. If the procurement process of your organization requires a different purchasing process, please contact Berlin Product People GmbH directly.