Agile product management was first developed as a reaction to various challenges that occurred in more sequential forms of project organization. As technology projects became increasingly complex, many product developers needed to replace their old style of management with a more iterative and flexible one–leaving room to refine long term requirements as the product advanced.
Agile is a set of techniques that take ‘user stories’ as the primary input and produce working software in small, incremental, success-based iterations. As much as its contributed to popular frameworks like Lean Startup, much of agile’s actual practice has been ‘captured’ by exactly the kind of orthodoxy and ordained expertise it set out to avoid.
That is a pity, but in principle, it’s easily fixed. The fundamentals of agile are easy to understand and apply, and they dovetail with popular concepts you may already be using like design thinking and Lean Startup.
Fun fact: agile was introduced in 2001 as a set of very simple ideas about how to improve product development. It’s ‘manifesto’ was only 68 words long and the meat of it was that:
|Individual Interactions||>||Processes & Tools|
|Working Software||>||Comprehensive Documentation|
|Customer Collaboration||>||Contract Negotiation|
|Responding to Change||>||Following a Plan|
Agile’s primary input is ‘user stories’ which have this syntax:
I want to [do something]
so that I can [derive a benefit]
Epic stories, which are more general, have child stories within them for more detail. Against these stories you write test cases to articulate additional points around the story.
You take these stories and sort them in priority order and work through a set of them in a given iteration. Classically, an iteration was 2-6 weeks, though with shortening product cycles more and more firms are at the shorter end of that, 2-3 weeks. At the end of each iteration, you have working product (which you may or may not release to the market but that you can validate or invalidate internally).
Since 2001, product cycles have gotten shorter, software (relatively) easier to build and distribute, and the amount of choice and information available to users has exploded.
All this has increased the relative importance of figuring out what to build relative to building. As a product person today, it’s extremely important to have an acute understanding of who you’re selling to and what they want before you start building stuff.
Getting there in a systematic way is the subject of my little box of tricks, called Venture Design, including the class I teach at GA. The diagrams below summarize this process (forward and reverse), including the role of agile’s ‘user stories’:
As you can see, they fit into a modern approach to product quite nicely. What may not be obvious from the summary is how well they dovetail with today’s best practices and how you can use that to generate easy wins for yourself.
3 Easy Wins
If you’re not really doing agile or only loosely involved in its practice, here are three easy wins.
1. Stop Writing “Requirements”
The whole notion of requirements invites a formalism and permanence to product development that it doesn’t need or want. Try user stories instead. If you’re obliged to write requirements, try them as a supplemental measure in key places.
I think what you’ll find is that they do a much better job of helping you think through the experience that you want the user to have and describing that to your collaborators in development.
2. Use Design Thinking to Write Great User Stories
If/when you find yourself writing stories, try linking them back to personas, problem scenarios, and value propositions as you see in the diagram above. The practice of design thinking is about asking yourself if you really understand what makes your user (and/or buyer) tick.
3. Manage Uncertainty with Lean/Startup & Small Batches
Have you spent more time that you’d like going back and forth with others about what to build and why? Lean Startup is a great tool here and builds, plus links to the practice of agile. One of its core tenets is the idea of articulating your key assumptions and then figuring out how you can quickly and inexpensively prove or disprove them.
Every perspective about what should be done rests on assumptions. Get those on the table, link them to your stories with validation criteria and you’re experimenting vs. arguing. The use of short cycle iterations in agile complements this in that you get your answers quickly.
Most of these should flow pretty naturally into your regular activities. If you’re an individual contributor, my advice is to try these out in a low profile fashion, proving to yourself and then (probably more gradually) to others that they’re effective.
Want to Learn More?
If you’re in the SF Bay Area and interested in how tools like design thinking, Lean Startup, customer development and the Business Model Canvas fit into best practice development using agile, you might want to check out my ‘Venture Design’ class at GA. We have a new session starting Sunday August 24th.