Hands-on Agile Webinar #1: Product Discovery Anti-Patterns
•Als PPTX, PDF herunterladen•
3 gefällt mir•1,174 views
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 what 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. 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. BLOG: https://age-of-product.com/webinar-product-discovery/ YOUTUBE: https://www.youtube.com/edit?o=U&video_id=rW2kVanMxMM
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Mehr von Stefan Wolpers
Mehr von Stefan Wolpers (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Hands-on Agile Webinar #1: Product Discovery Anti-Patterns
- 2. About Stefan Wolpers Agile Coach, Scrum Master, and Product Owner since 2006: stefan@age-of-product.com
- 20. Psychological Issues (Tricked by Your Brain) stefan@age-of-product.com
- 26. Contact Information Stefan Wolpers Email: stefan@age-of-product.com Blog: Age-of-Product.com Newsletter: https://age-of-product.com/subscribe (Join 16,000 peers) Slack: https://hands-onagile.slack.com/ (Join 3,000 peers) Twitter 1: @StefanW Twitter 2: @AgeOfProduct
Hinweis der Redaktion
- Good morning, good afternoon, good evening Welcome to the hands-on agile webinar on product discovery anti-patterns I am your host, Stefan Wolpers Some housekeeping: The webinar will take about 25 to 30 minutes which will leave enough room for Q&A at the end
- Some background on myself: I have spent 12-plus years in agile Mostly as a product owner in fast growing, vc-funded startups in Berlin (including a later Google subsidiary) At the moment, I am working as an agile coach/scrum master for a large european electricity and gas provider
- my first outreach on product discovery anti-patterns to the agile community was in late 2017 with a blog post I mentioned the product discovery void in the scrum framework (given scrum’s popularity and because scrum is often equated with agile ) I put a lot of effort into that post but the feedback was unexpected
- The prevailing repsonse was… Which is precisely the issue I wanted to point at — garbage in, garbage out In my experience, scrum is ideally suited to build a product efficiently nobody wants
- As far as product discovery in scrum is concerned, it is all outsourced to this mystical role of the product owner According to the Scrum Guide: => slides So, the product owner has ideas, or identifies ideas, or at least he or she curates suitable ideas from wherever And validates them whether those ideas are “product backlog worthy” Interestingly, the scrum guide also states: „The Product Owner may do the above work, or have the Development Team do it.“ Which is really not helpful to support the understanding the role of the PO, particularly on the management side So, in my experience, this approach turns the product owner into the Achilles heel of the whole process. Even worse, if you "remove" the PO as an independent and respected role, for example, by sticking with your organizations’s stage-gate process, Scrum easily mutates into a Waterfall 2.0 process.
- So, let’s move from scrum to a holistic perspective on "agile product development" Let me introduce you to my mental model of how agile (for software products) works: You start with a vision on the left side And you end up with delivering code at will to a resilient system on the right side
- I label the left side “product discovery” And the right side “product delivery” Of cource, the separation is not as strict; both parts are overlapping somewhere in the “near term planning” era. (In scrum speak it is usual the product backlog)
- Now, product discovery tends to be much more affordable and low tech on the left side, And much more expensive the further you move to the right side It is literally comparing “a napkin” to a “a full-blown continuous delivery pipeline"
- From a risk mitigation point of view, the further to the left product discovery happens, the earlier in the process, the better.
- Although most people agree to these simple basics of a post-industrial product creation process at a conceptual or meta level, Applying these basics, in reality, however, turns out to be something completely different — there are product discovery anti-patterns all over the place, no matter what organization we talk about in this regard. That happens to startups as well as General Electric. In my experience, there are three main categories for product discovery anti-patterns : systemic, personal, and psychological issues. Moreover, to make things worse, those categories are not isolated from each other. Anti-patterns may fall in two categories at the same time.
- You will find systemic issues, for example, in all organizations from the industrial era: Functional silos, a rigid budgeting process, hierarchies from the 1920ies prove to be a fertile ground for systemic product discovery anti-patterns
- Also know as: We know what to build Think Jira monkeys & coders, and treating the product department as an internal agency (“we pay you”), This anti-pattern leads often to Conway’s law: you are shipping the org-chart, as its communications structures are incorporated into your product This results typically in local optimization efforts within a siloed organization
- Speaking of silos: Siloes, for example, marketing or sales, insist on channeling communication with customer and users. So, the sales people prevent “product” from talking directly with customers which makes user interview, user research very problematic, particularly in the B2B sector. This inevitably leads to a massive loss of information and context as the silo is operating under a different mental model than product.
- Engineers are supposed to deliver “code.” They are not supposed to talk to customers or take over customer support duties to get the first-hand experience of customer problems. That is pure Taylorism at work, entirely output oriented. The problem is, we are no longer assembling Model-Ts. But we go every day, where no one has ever gone before. Rule of thumb: Coding is less than 30% of the whole effort — the best way to increase productivity of the product team is to avoid building unnecessary stuff
- Okay, let’s not assume a victim role and have a look in our backyard: There is one issue that regularly triggers frustration on the side of the stakeholders: "Product" is not transparent about how they work, how a suggestion/ idea/requirement can make it into a sprint. =>this black box approach reduces stakeholders’ willingness to collaborate across the board, impeding product discovery.
- Politics and personal agendas do not require any introduction, I assume.
- Pet projects are often stakeholder driven. However, they do not exclusively apply to the middle management. 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 for me?” syndrome. It could be, for example, a CV optimization for the next career step. Or it is about “loving your solution” and not the problem. The resulting high personal investments can lead to the blame game, death marches & other face-saving techniques at the expense of product discovery.
- 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 is 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; the lonesome innovator is a myth. Yet, submission to the will of one with the higher status is often common. (Except for Google, maybe.)
- Bonus at risk: Shortly before the end to of the bonus period the product team gets swamped with “must have” requirements from sales. Typical manifestations are: Selling specific features that close a contract without talking to product. A ,more desperate attempt: Making assumptions that certain new features will bring new business. (throw something at the wall and see what sticks.)
- The last category is the fun category as it opens the field of cognitive science or how we like to trick ourselves into believing something.
- The Sunk Cost Fallacy: We believe that we make rational decisions. In fact, we are often only rationalizing them afterwards. One mind trick is the sunk cost fallacy: here, our aversion loss – gee, we already invested so much — overrides the rational decision, for example, cut losses. I do not know whether you are also tuning in to the soap opera callee “Berlin’s new airport” from time to time, However, it is a good example for the sunk cost fallacy. Planned from 1991 on, construction started in 2006, and 2011 was the supposed grand opening. Did not work due massive violations of safety standards. Kahnemann: “Thinking, fast and slow.” Dan Ariely “Predictably Irrational”
- The Self-fulfilling Prophecy: With the best intentions, you want to validate your hypothesis or solution. However, your confirmation bias lets you unconscious pick the a set-up that will deliver the ”confirmation” — by a self-fulfilling prophecy. That has happened twice to me over the years: as a chemistry student in the labs — at least that resulted in a good discussion with my professor of organic chemistry at the time — and then there was Ebookmakr, a failed application to create ebooks online. (We “picked” the wrong participants for the user-tests.)
- Wikipedia: Survivorship bias or survival bias is the logical error of concentrating on the people or things that made it past some selection process and overlooking those that did not, typically because of their lack of visibility.
- 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 called this effect psychological distance—that is, gaps between yourself and other people (social distance), the present and the future (temporal distance), your physical location and faraway places (spatial distance), or imagining something and experiencing it (experiential distance): Asking users what they need is often overburdening them — they will probably have no clue. And if there is a problem they 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?) At the same time, people want to be helpful. So, if you ask users what they need they will provide an answer. Be cautious, though, only money talks. Alternatively, observe how your customers work. If you show prototypes, use wireframes, not polished designs.
- So, I hoped you considered this webinar of product discovery anti-patterns useful. The next webinar will in two weeks time from now. It will cover the results of a recent survey on which factors are indicating the an organization is agile. And I will also introduce a new open source project — the Agility Assessment Framework — which will support scrum master and agile coaches to figure out the (air-quotes) “state of agile” of an organization.