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.

During the course, I play an over-the-top, big bad boss and hand out a high-level initiative for a mobile app. As I explain how this solution helps our firm compete in the mobile space, the reactions are precious. Participants will argue that it’s not a unique offering while others will counter that it’s what we’ve got to work with. Some just check out their fantasy baseball teams.

I try bringing them around by pointing out that as the big boss, I’ve hired an Agile coach (also played by me) to help us through. I then highlight the pressure we’re under to stay viable and if this doesn’t work out, we might go out of business.

As we go out and research the current experience, the teams come back with the conclusion that people are satisfied with many preexisting solutions and that ours offers no detectable competitive advantage.

rejected by Sean MacEntee

The big boss (that’s me) is not interested in this information and points out that’s why we’re doing some discovery! The team needs to figure out how to make this work, learn what will get people to use it, and keep going.

As the boss, I tell them that I’ve contracted an outside vendor to help detail out the features and because we’re “going Agile,” the vendor has written them all as user stories. This allows the Agile coach (me, again) to lay out a story map. We plumb the map for opportunities, and look at how to measure success against our MVP experiments.

Nothing seems to matter. Not enough people want it.  Some of the teams try to add in novel items, while others look to adapt the solution a little to match a need. Or create their starting lineup for their fantasy baseball team. The ones who make progress look at building an entirely different app.

A happy worker is a jumpy worker? by Happy Worker

It’s at this time that as the Agile coach,  I say that I’ve had a talk with the big bad boss and he’s relented. The overwhelming evidence that what we’re building isn’t wanted and we’re running the chance of being put out of business, the big boss says that we can change direction. Whatever the teams decide to do, he insists that it must show off our firm’s talent in the mobile space.

People get excited, reinvigorated and forget about their fantasy baseball teams. Some teams leverage what’s been done to date, and others scrap it. Ideas flourish and solve a problem people have, or give them a different experience. People want it.

After training, teams would go back and face similar situations. As I was going along for the ride in a coaching capacity, I’d have them recall what they went through to get the big, bad boss to relent. Things like:

  • collect evidence on current usage
  • create a story map of all the features requested, and line them up to outcomes
  • conduct small experiments to find and test what’s minimally viable
  • do some skunkworks and create alternative solutions
  • walk through not only why the solution doesn’t work, but also what will work

It took longer than a couple of hours to get the buy-in to change direction. Sometimes weeks, sometimes months. Usually, however, the situation eventually did change. It turns the discovery effort from justifying the solution, into learning what’s needed.

It’s MAD- a series of Misadventures in Agile Discovery is brought to you by Aaron Sanders. You should follow him on twitter @_aaron_sanders

This entry was posted in #agile explained and tagged , , , . Bookmark the permalink.

Comments are closed.