Agile practices typically have the development team interact with a single “product owner”. This person is designated to decide what gets built, how it behaves, and whether it has been delivered to specification. Essentially, the Product Owner represents the rest of the world so that the developers can focus on building software.
Developers are given permission (if they choose) to act as order-takers, absolved of responsibility (and accountability) for understanding why the thing is being built, and what the product is setting out to do.
In order to create products that customers and users love, the “owner” role must include three distinct responsibilities, divided across a balanced team of owners — each as important as the other.
Teams that share accountability for product ownership tend to invent better solutions and achieve traction faster with less internal friction. This balanced team approach was first advocated by Tim McCoy, formerly Director of Integrated Product Development at Cooper.
Solo work can be invisible to others. When you work as a startup team you have to get ideas, decisions, concepts and conclusions out onto the walls where others can keep up. Whether you’re telling people what you’re working on, announcing progress against goals, deciding priorities, or designing new features, Lean teams do it on the walls. Both User Experience and Agile practices have rich histories that you can draw upon for showing information and collaborating in shared spaces, ideally in physical space.
As much as possible without succumbing to dogma, define your methods of working so that they can be repeated, then make those methods routine. Knowing “this is how we do X” accelerates your growing organization. Repeatable, routinized methods make it easy to teach new employees and allow you to focus on the important things: your customers, their problems, and the solution that you’re crafting.
In all things, Lean UX is driving toward a goal — to understand a user, to change a metric, to solve a problem. It is not sufficient to aim at a goal, though, we must also observe the outcome and note whether we hit the goal. And if not, we need to try again.
This is the UX analog to Lean Startup’s “build-measure-learn” feedback loop. Designers prefer to start with “think” rather than “make”, but the process is the same. UX people start with research that’s equivalent to the customer development interview. The innovation with Lean UX is that we choose lightweight research methods, move on quickly to make a small prototype that will prove out the riskiest concepts, and then validate that through some sort of real-world test. The most important success metric for any startup is the time it takes to move through the think-make-check (or Build-Measure-Learn) cycle.
The easiest way to begin designing is to fire up the computer and start making wireframes or page comps. The easiest way to envision a product is to list out the features. Both starting points are fraught with risk. To build the right product, you must know the problems that your customers have and solve them, one at a time, starting with the most important.
Eric Ries says that the defining characteristic of the startup is that entrepreneurs must invent solutions despite conditions of “extreme uncertainty”. In this environment, the best creative approach is to generate many ideas, and using your best insight, choose one or two to move forward with. The Stanford d.school calls this process “flair and focus”. When you work as a team, you have many brains to contribute to creating many options. Having sessions where everyone creates multiple ideas creates a sufficiency of options, so that you raise the caliber of ideas that move forward.
In the “flair and focus” process, this is where focus comes in. When choosing what to pursue from a wide set of options, choose decisively but hold the decision lightly — be prepared to change it or try another solution if it doesn’t work. Throwing away work is part of the invention process. (Remember, in a Lean Startup the unit of progress for startups is “validated learning”, not number of features.)
When you think about it objectively, every decision we make is a hypothesis, a best guess: Your design is a hypothesis. The backlog order is a hypothesis. The product roadmap is a hypothesis. To test that your product decisions are right and good, build the smallest thing you can and put it out into the world as a test. Use quantitative or qualitative research to see if you were right. If you weren’t, go back to the pile of unused ideas and try again. Realistically, you won’t be able to validate every hypothesis, so test those that are mission-critical.
“I Like It” are dangerous words in an entrepreneurial company. We are all tainted, if only because of our endless pondering about the product we’re making. The only way to know whether our ideas are the right ones is to talk with users & watch their behavior. If you find yourself in a meeting having an “I think…You think” conversation, ask yourself “Does this matter enough to test it with customers?”. If yes, then build an MVP and test it. If not, then stop bickering, figure out who “owns” the decision, and let them make the call. (If it doesn’t matter enough to test…then it probably doesn’t matter enough to argue over.)
Agile practices typically have the development team interact with a single “product owner”. This person is designated to decide what gets built, how it behaves, and whether it has been delivered to specification. Essentially, the Product Owner represents the rest of the world so that the developers can focus on building software.
Developers are given permission (if they choose) to act as order-takers, absolved of responsibility (and accountability) for understanding why the thing is being built, and what the product is setting out to do.
In order to create products that customers and users love, the “owner” role must include three distinct responsibilities, divided across a balanced team of owners — each as important as the other.
Teams that share accountability for product ownership tend to invent better solutions and achieve traction faster with less internal friction. This balanced team approach was first advocated by Tim McCoy, formerly Director of Integrated Product Development at Cooper.
Solo work can be invisible to others. When you work as a startup team you have to get ideas, decisions, concepts and conclusions out onto the walls where others can keep up. Whether you’re telling people what you’re working on, announcing progress against goals, deciding priorities, or designing new features, Lean teams do it on the walls. Both User Experience and Agile practices have rich histories that you can draw upon for showing information and collaborating in shared spaces, ideally in physical space.
As much as possible without succumbing to dogma, define your methods of working so that they can be repeated, then make those methods routine. Knowing “this is how we do X” accelerates your growing organization. Repeatable, routinized methods make it easy to teach new employees and allow you to focus on the important things: your customers, their problems, and the solution that you’re crafting.
In all things, Lean UX is driving toward a goal — to understand a user, to change a metric, to solve a problem. It is not sufficient to aim at a goal, though, we must also observe the outcome and note whether we hit the goal. And if not, we need to try again.
This is the UX analog to Lean Startup’s “build-measure-learn” feedback loop. Designers prefer to start with “think” rather than “make”, but the process is the same. UX people start with research that’s equivalent to the customer development interview. The innovation with Lean UX is that we choose lightweight research methods, move on quickly to make a small prototype that will prove out the riskiest concepts, and then validate that through some sort of real-world test. The most important success metric for any startup is the time it takes to move through the think-make-check (or Build-Measure-Learn) cycle.
The easiest way to begin designing is to fire up the computer and start making wireframes or page comps. The easiest way to envision a product is to list out the features. Both starting points are fraught with risk. To build the right product, you must know the problems that your customers have and solve them, one at a time, starting with the most important.
Eric Ries says that the defining characteristic of the startup is that entrepreneurs must invent solutions despite conditions of “extreme uncertainty”. In this environment, the best creative approach is to generate many ideas, and using your best insight, choose one or two to move forward with. The Stanford d.school calls this process “flair and focus”. When you work as a team, you have many brains to contribute to creating many options. Having sessions where everyone creates multiple ideas creates a sufficiency of options, so that you raise the caliber of ideas that move forward.
In the “flair and focus” process, this is where focus comes in. When choosing what to pursue from a wide set of options, choose decisively but hold the decision lightly — be prepared to change it or try another solution if it doesn’t work. Throwing away work is part of the invention process. (Remember, in a Lean Startup the unit of progress for startups is “validated learning”, not number of features.)
When you think about it objectively, every decision we make is a hypothesis, a best guess: Your design is a hypothesis. The backlog order is a hypothesis. The product roadmap is a hypothesis. To test that your product decisions are right and good, build the smallest thing you can and put it out into the world as a test. Use quantitative or qualitative research to see if you were right. If you weren’t, go back to the pile of unused ideas and try again. Realistically, you won’t be able to validate every hypothesis, so test those that are mission-critical.
“I Like It” are dangerous words in an entrepreneurial company. We are all tainted, if only because of our endless pondering about the product we’re making. The only way to know whether our ideas are the right ones is to talk with users & watch their behavior. If you find yourself in a meeting having an “I think…You think” conversation, ask yourself “Does this matter enough to test it with customers?”. If yes, then build an MVP and test it. If not, then stop bickering, figure out who “owns” the decision, and let them make the call. (If it doesn’t matter enough to test…then it probably doesn’t matter enough to argue over.)
