Tag Archives: product discovery

It’s MAD to Build everything that goes through discovery

People nod heads with a knowing look when someone informs them that less than 50% of ideas make it to market.  That may even seem generous. Companies practicing continuous product discovery collect data on the impact and unofficially report numbers far lower than 50%. These companies test multiple ideas weekly and most are not pursued.

#agile explained | Tagged , , , , | Leave a comment

It’s MAD to Use Discovery to Justify the Solution

Have you ever had an executive, a board member, or some other high-ranking person tell you what to build? How were you able to stand up to them? And keep your job? Decreeing the solution happens with such regularity that my Product Owner course is designed to mimic the situation.

#agile explained | Tagged , , , | Leave a comment

It’s MAD to Put All Work Through Discovery

I was sitting with a team when their manager came in and asked, “Hey. Are you guys finished with this feature?” The Scrum Master responded, “We haven’t even had time to even begin the discovery on it yet.” The manager looked surprised and said, “Oh, OK. Would you let me know when I can see it?” and walked out. It really surprised me as the feature seemed trivial and so I asked, “What do you need to learn about this? It seems really straight-forward.” “You’re right.” he said, “We could just build this. But we don’t want to.”

#agile explained | Tagged , , , , | Leave a comment

It’s MAD to Have a Separate Discovery Phase

Here we are with another Misadventure in Agile Discovery (MAD). This one pairs well with the first misadventure, the separate discovery team. Even when that mistake is corrected and a balanced team is working together through discovery and delivery, the team may decide to spend some time furiously creating a slew of new ideas.

#agile explained | Tagged , , , , | 2 Comments

It’s MAD to Have a Separate Discovery Team

Diving deeper into the first item on the list of Misadventures of Agile Discovery (MAD), let’s look into the problem of having a separate discovery team. Let me start with a couple of stories.

#agile explained | Tagged , , , , , | Leave a comment

Misadventures in Agile Discovery: Top Ten Common Mistakes

I’m going to admit something to you as an Agile coach. Clients that I work with make mistakes, and I can’t prevent them all. I don’t even try to.

#agile explained | Tagged , , , , | Leave a comment

Describing Agile Product Discovery

Agile product discovery works in tandem with delivery. The best effect comes when it includes the whole team, is done deliberately and continuously. The video includes the common roles, artifacts and ceremonies involved in discovery. While this is the first of many iterations to come, I hope you enjoy! What questions do you have, or feedback you would like to provide?

#agile explained | Tagged , , | 1 Comment

How to start discovery on your Scrum team

How do you get started with discovery on your Scrum team? Participants learn how to improve practices like user research and interviews, persona sketching, design studio, prototyping and story mapping by actively using them in a class. At the end of the class, participants see a different way of working. Then the discussion turns to something like- While this is undoubtedly is a better way to work, it’s so different than what we do today. How can we do this stuff where we work? How do you get started?

#agile explained | Tagged , , | Leave a comment

Consequences of Thinking, Fast and Slow on User Interviews

This is the first (second?) post on a series on how my coaching and training style may change, based on the book Thinking, Fast and Slow.

#agile explained | Tagged , , | Leave a comment

dual track Scrum in brief

Coining the term “dual track” Desireé Sy‘s Adapting Usability Investigations for Agile User-centered Design(pdf) (2007) might be one of the first examples drawing out and labeling a process knows as dual track Scrum and stating, Although the dual tracks depicted (…) seem separate, in reality, interaction designers need to communicate every day with developers. This is not only to ensure that designs are being implemented correctly, but also so that we have a thorough understanding of technical constraints that affect design decisions

#agile explained | Tagged , , , , | 2 Comments