Product Innovation in Agile
Contributed by Hugh BeyerAgile and innovation. Cats and dogs. Chocolate ice cream and white shirts. Some people say these things just don’t go together.I’m going to say they can and do, but let’s acknowledge the problem first: there is nothing in Agile methods which are particularly going to help you think long-term, strategically, or out of the box. Agile methods are structured to keep you focused on the day-to-day, ensuring that you do the next most important thing to improve your product (or get to a viable product). Whether your sprints are two weeks, or one week, or you’re doing continuous integration, everything is focused on the short term.User stories are no help either. A story has to be completed in a single sprint—so it’s guaranteed to be a small chunk of functionality. How does it build towards some larger, strategic goal? Agile itself doesn’t say. And if you over-focus on the individual stories, you’ll lose sight of the end goal yourself.None of this is a problem with Agile. Agile is focused on making development work. As a product manager, you job is to not get caught up in the day-to-day cranking of the wheel. You have to have a hand on the wheel while still looking ahead to make sure you’re going in the right direction. But how do you do that when everything in the Agile process is encouraging you to focus on the short term?Below is a diagram that I created to describe the role of UX in developing a product, but it works pretty well to describe what product managers are up to also. Agile will try to focus you on the bottom two layers—write stories and get them into production. But the meat of the job is the top three layers. Who are the customers? What do they need? How do we get it to them? Those questions have to be answered—at least provisionally—before the first story is written.
But, assuming you’re working in an Agile organization, you don’t have the luxury of doing all that before development starts. You have to do it while shipping value. And that means that in every sprint, you should expect be doing work at every level of the diagram. If you focus too much on the top layers, your development team goes hungry. If you focus too much on the bottom, you lose contact with your customers and start making stuff up. Too much focus in the middle and you’re smoking your own exhaust, making beautiful plans with no practical effect.Each of the layers addresses a piece of the job:
- Research—Who are the customers? What do they want? What do they need that they don’t know to ask for? How do they work? What are their values? The answer to these questions can be the difference between a product that’s loved and one that’s ignored. Key techniques are field interviews, surveys, market research, and competitive analysis. But don’t neglect the field research—that’s the only way you’ll know what’s really going on with your customers.
- Strategy—How do you respond as a business? Where can you make money? What are you as a business good at? How do you bring value to the market? Your strategy has to align not just with what customers need, but with your own capabilities and direction. You need the business stakeholders involved at this point. You want a concrete representation of this strategy because it is going to take many sprints to achieve.
- Requirements—What are you going to bring to market? What are the features and how are they structured? How will your product improve the way people work? This is the domain of requirements definition, but storyboarding is a key technique here. Look at proposed new features from the point of view of the users’ day-to-day life. This is also the point where architecture becomes important—what’s the right underlying structure to support the product concept?
- Design—What is the look and interactivity that will deliver your product concept? How does it support your brand and company image?
- Implementation—How will you build all that? What are the problems that will get in the way? How will you make the inevitable tradeoffs without losing your strategic direction?
So ask yourself every sprint: What is my team going to accomplish this next sprint? Where is the strategic focus in this sprint? Are we doing the next most important thing to realize the strategy? If not, what specific actions do we need to take to recover it?Image from Flickr Commons
Hugh Beyer is a UX designer and thought leader with extensive experience in a wide variety of industries and product types. He has a strong track record creating innovative designs through user research, needs analysis, ideation and iteration, and of guiding teams through these activities. His broad background and wide-ranging interests give him unique insight on what leverage points an enterprise has to delight their customers. Hugh is also a thought leader and innovator in the area of Agile Development, working with agile teams since 2004. He wrote one of the first papers on integrating UX techniques with agile in 2004, and has published a book on user-centered agile methods.