Defining Problems at ProductCamp Austin 1

Jun 14th was the first productcamp in Austin (and the second one anywhere). It was a great event, and here’s the presentation that I did on how to define the strategic problems that drive our products.

Defining Problems

Here’s the presentation I gave at ProductCampAustin 1, posted on slideshare. Just click on the forward/back arrows in the center of the bottom of the image, and it will cycle through the presentation – you don’t even have to leave Tyner Blain.

| View | Upload your own

Following Along

In keeping with the “don’t put a lot of words on your slides” tradition, the presentation is probably all but impossible to follow without some notes. So here are some notes, organized by slide. The presentation builds on concepts we’ve talked about here over the years, and in the notes below, I’ll link to some of those previous articles to provide more depth (instead of typing out everything I said).

• Slide 1. There are two key elements to achieving software product success. Build the right stuff, and build it right. This presentation is about building the right stuff.
• Slide 2. Specifically, when we start a project, it is to achieve some business objective. The challenge is to find the right level of abstraction for that objective. “Increase shareholder value” is too nebulous, and “Replace a legacy system” is too lacking in context. Today we will apply a very powerful, but simple technique to help define the business objectives at the right level of detail to be actionable, while providing the right context to validate that we’re doing the right thing. My goal is for everyone to leave here with a new skill that they can immediately apply.
• Slide 3. Everyone has a different perspective on a software project, and from those vantage points, perceives different elements of the project as the “why, what, and how” of the project.
• Slide 4. Keeping in mind that people have different perspectives, let’s also look at a modified version of Karl Wiegers’ structured approach to requirements definition.
• Slide 5. Introducing the Ishikawa diagram.
• Slide 6. Set up the “deflated tires” problem from the article linked in (slide 5).
• Slide 7. Showed the discovery process and representation of “real problems” closing out the theme from slides 5 and 6.
• Slide 8. A real-world project I joined mid-stream for a client. The project was a “collection of stuff” and no two people would give the same answer for “why are we doing it” and many people unashamedly admitted that they had no idea why. No idea why!
• Slide 9. Turns out, here’s what a view of the value for that program really looked like. The team went from chaos to context. Suddenly, scope discussions and prioritization decisions had a framework for validation. There was also an organized way to begin completeness analysis. Much easier to say “we’re getting this value” than to say “we’re doing these things – did we miss anything?”
• Slide 10. I facilitated the folks in the room creating an Ishikawa from scratch. We started with what we thought was the problem statement (provided by John Milburn from the back of the room) – “Traffic in Austin on Fridays is too bad.” We ended with “John has work-life balance problems”, one of which comes from missing dinner with his wife, which can happen because of a combination of bad traffic and bad planning by John. We also explored several solution-paths, including increasing the capacity of the roads and of the vehicles. The ideas clicked for several people in the room.
• Slide 11. Another real-world example, this one used in planning of a product roadmap for an 18-24 month view of the problems the team was signing up to solve.
• Slide 12. Special thanks to the sponsors that made our inaugural ProductCampAustin a success! My prediction for the next one (fall/winter 2008): 250 attendees. So if you’re the sponsoring type, start planning on how you can help out.

Thanks again to everyone who attended, and special thanks to Tal Boyd of Seilevel, who video taped my whole presentation. I just haven’t figured out how to split the 400+MB m4v file into something I can upload onto youtube.