A great Product Owner is critical for any company or team using an agile approach to software development. In Agile Product Management with Scrum: Creating Products that Customers Love) Roman Pichler focuses on this key role. Although it’s tempting to think of a product owner as just a new name for product manager, Pichler elaborates on the differences between these two roles. The product owner encompasses both traditional functions: product manager and product marketing manager. “Uniting the two product management aspects,” writes Pichler, “achieves end-to-end authority and accountability. We avoid handoffs, waiting, and delays as well as miscommunication and defects.”
Pichler provides specific advice to product owners with common mistakes related to each area of agile product management. Each chapter has a set of reflective questions to compare current state product development processes to those described in the book. To assist new product owners, there is one chapter devoted to transitioning into the role. He gives specific advice on creating a product vision, managing the product backlog, release planning, and participation in Scrum meetings. He provides a lot of detail to complement the concepts and method.
The customer, who is the person purchasing the product, and the user, who is the individual using the product, determine the success or failure of the product.
A new paradigm for product management
Agile product management is different from traditional product management in several key areas. The product manager role and the Scrum team enable agile product management to take a different approach to challenges which have plagued software development.
|Old School||New School|
|The product marketing manager, product manager, and project manager share responsibility for building and delivering the product.||The Product Owner is responsible for the product and leadership of the project.|
|Product managers are separated from development teams by processes and reporting relationships.||The Product Owner is a member of the Scrum team responsible for delivery of the product.|
|Market research, product planning and business analysis activities are performed at the beginning of the project.||A minimal product vision is created up front to allow the team to begin moving forward quickly. A dynamic product backlog is in place to capture and respond to change.|
|Discovery activities and requirements definition is performed at the beginning of the project and frozen for the duration.||As the team learns and new knowledge is generated, the product backlog changes accordingly. There is no up front requirements definition phase to specify the entire system.|
|Customer feedback is solicited during market testing and after launch.||Regular, incremental and iterative releases combined with weekly sprint reviews supply customer and user feedback.|
The Product Owner
The product owner is a visionary who can envision the final product and communicate the vision. The product manager is also a doer who sees the vision through to completion. This includes describing requirements, closely collaborating with the team, accepting or rejecting work results, and steering the project by tracking and forecasting its progress. As an entrepreneur, the product owner facilitates creativity; encourages innovation; and is comfortable with change, ambiguity, debate, conflict, playfulness, experimentation and informed risk taking.
The Product Owner role, as “first among peers”, spans many activities traditionally split across multiple individuals:
- creating the product vision
- grooming the product backlog
- planning the release
- involving customers, users, and other stakeholders in product development
- managing the project budget
- preparing the product launch
- attending Scrum meetings and collaborating with the team
The product owner takes an inward view (traditionally the domain of a product manager) and an outward view (usually the focus of a product marketing manager) of the product and business. A visionary and the person responsible for relentlessly driving the vision to completion, the product owner is both a team leader and a team player. A successful product owner must be entrepreneurial, a great communicator, an adept negotiator, empowered, and committed to the success of the product, the team, and the business.
The Scrum team has many of the qualities of any great team: trust, collaboration, sufficient resources, sponsorship, closeness to the customer, and a common goal. Breaking down organizational barriers (within the company and between the company and its customers) are reinforced by many aspects of the agile method.
The team itself is self-organizing, cross-functional, and small. It should include all roles required to bring the product to life. All members of the Scrum team must form a close and trusing relationship, a symbiosis, and work together as peers. There must be no us and them. There can only be us.
Although the product owner effectively has end-to-end responsibility for delivering the product, she can reach across the organization to get support and assistance from senior executives and other functional leaders. This broadens the resource set available to the product owner while maintaing responsibility and accountability with one individual. With respect to project managment activities, Pichler says they are “no longer exercised by one person.” With the agile approach, these responsibilities are divided between the members of the Scrum team.
The product owner role can scale up by with a Chief Product Owner to whom several product owners report. Each product owner can be responsible for a feature or a component of the overall product. This addresses a frequent question about the agile approach: can it scale?
The Product Vision
The product vision is a foundational element of the agile approach and guides the team to its destination. A good vision answers the following questions:
- Who is the customer and the user of the product?
- What customer needs are fulfilled by the product?
- What is the value proposition?
- What attributes of the product are most important for meeting the customer needs?
- How is the product different from other offerings?
- What is the business model?
- Can the product be developed by the company given its resources and capabilities?
A great vision must be shared by the team and unify everyone involved. A broad and engaging vision will inspire and endure. Pichler advises using Ockham’s Razor to achieve a vision that is “short and sweet”–seek the simplest solution. Common mistakes to avoid when developing a vision are attempts at prophesy, paralysis through excessive analysis, and seeking perfection.
Methods to arrive at a product vision include using small projects incubated as part of “innovation time”, including vision exercises in the product backlog, prototypes and mockups, personas and scenarios, a vision box, and Kano model (also read “Leveraging the Kano Model for Optimal Results” at UX Magazine).
The Product Backlog
The backlog contains a prioritized list of all incomplete work items required to achieve the product vision. Items in the product backlog are ordered by priority and level of refinement. The most detailed and granular items are at the top, ready for the team to implement, while more coarse-grained and less well defined items (themes) are at the bottom.
Requirements are no longer frozen early on but instead are discovered and detailed throughout the entire project. As our understanding of customer needs and how they can be best met improves, existing requirements are likely to change or become redundant, and new requirements will emerge. Product discovery is therefore not limited to the early development stages, but covers the entire project in Scrum.
To guard against creating a backlog which is a dumping ground for every product idea anyone ever had, Pichler recommends focusing intensely on the customer need and ensuring that each and every backlog item clearly benefits the customer. Only the minimum functionality required to fulfill the customer need should be considered by the team–simplicity is your friend. Adding too much detail early on can overwhelm the team and make it difficult to prioritize.
Treat existing requirements as suspicious and consider them as a liability, not an asset.
A key to prioritizing the backlog is to prioritize themes first. This effectively orders the more detailed backlog items because the higher level groupings are in the right sequence. The backlog is frequently a mix of themes, epics, and stories. It’s the product owner’s responsibility to continually groom the backlog to provide a clear set of priorities for the team. Decomposing complex backlog items into more granular items is another key product owner activity.
Using the product vision as a guide, the product owner prioritizes backlog items based on customer value, risk, releasability, and dependencies. Front-loading risk can help the team learn and expose critical assumptions and assist architecture design and technology selection.
The Scrum team and Planning
As the product owner, you guide and influence the team. Your behavior matters. A lot. Frequently reflect on your intentions and actions.
In addition to crafting the product vision and being responsible for grooming the backlog, the Product Owner is involved in release planning, sprint planning, daily stand-up meetings, and sprint retrospectives. Principles of effective agile planning include using actual velocity to estimate future delivery (as opposed to idealized plans that extend far into the future) and maintaining a sustainable pace (rather than attempting to increase output by increasing work hours).
Pichler notes that the days of the lone wolf product manager are long gone–product owners must be outward-facing, an integral part of the Scrum team, and committed to collaboration. Likewise, there is no manager or project manager in Scrum–the team is self-organized, manages its own work and is accountable for its goals. Stakeholder involvement is critical for the success of the Scrum team and this is facilitated both by the product owner and the sprint review meeting.
An Introduction to Scrum
Pull: The Power of the Semantic Web to Transform Your Business is about technology transforming the way we do business, but it can be read as a book on a new category of products and user experiences. David Siegel describes the pull era as a time when “customers pull everyting to them on demand – products, services, information, knowledge, and advice.” Siegel says “it’s a world where customers pull and companies respond.” In the pull world, “you specifify what you want and it finds you.” The technology basis for the concept of pull is the semantic web–making information available and easibly discoverable online with a common name space in an unambiguous format.
This book is mostly a set of futuristic scenarios categorized by the supporting technology or design concept. It’s a highly ambitious project and Siegel reaches into the legal, taxation, and health care domains to sketch out his vision for the semantic web, intelligent data stores, and new ways of doing business. Siegel’s vision is quite ambitious, reaching towards an artificial intelligence that is guided by semantic search and global ontologies. He does, however, match up each prediction with current-day examples of supporting technologies and standards initiatives.
The pull idea not only describes an ecosystem of products and services that we’ll be using in the future, it’s also a mindset and set of principles that product designers and developers can adopt as they build the next generation of hardware and software technology. Pull is a design manifesto for customer powered information exchange.
In the push model, the website is at the center and people come and go. In the pull era, you are at the center; web sites get your identiy credentials by permission and authentication, rather than by asking you to fill out forms.
This book is similar to Bruce Sterling’s Shaping Things in that it describes a category of products and services that today exist only in splinters. Siegel references spimes because any object with an RFID tag that generates metadata and knows its location in space and time qualifies as a spime. Siegel gives an extended culinary example: your refrigerator will adjust its temperature setting based on the requirements of the contents, it will order items when they are used up, and you’ll be able to query the kitchen for dinner ideas based on available ingredients. Similarly, a catalog owned by a distributor could connect to its customer inventory database to suggest orders, discounts, and replacement items. A running shoe manufacturer which embeds RFID tags in running shoes so runners can register for races and track their results in a single location is moving towards a pull model.
The Semantic Web
The semantic web tries to make sense of written and spoken language that we intuitively understand but computers normally don’t–usually qualitative information like reviews, opinions, descriptions, directions, and definitions.
Two tests for semantic web:
1. Is it semantic? Are the terms unambiguous and tagged in a royalty-free format, governed by a nonprofit organization, that all software programs can understand?
2. Is it on the web? Is it online using a common name space that makes it easily findable? Is it shared among collaborators or companies? Does it use the information already online to get smarter as more people use it?
Core Principles of Pull
- Automatic generation of metadata – As we move through our lives, each transaction, product, and service touchpoint will generate data that will be stored in our personal data locker. Some events will generate data that will be sent back to the manufacturer to improve future products. The metadata must be in a shareable, reusable format.
- A customer-centered view of data - Siegel sees a power shift from traditional push tactics used today by marketers and service providers to a cusomter-centric pull paradim in which customers decide who sees their data and who they want to have relationships with. Services align around customers to provide greater value. Companies will organize around customers and customer groups, not capabilities.
- Intelligent data stores – The personal data locker is a foundational concept for the pull era. All devices will have intelligent meta data generators and decision systems–your call will send system status information to the manufacturer and automatically schedule maintenance. Resumes and other standard document formats will build themselves.
- Intelligent marketing – One of the benefits of the pull concept for marketers is the end of ad targeting based on keyword search and profile information. In the pull era, personal data lockers will make their owners’ preferences known to marketers explicitly. Personal data lockers will have permissions and visiblity levels that will govern which marketing entities can view and interact with which data and preferences.
- Data ownership and portability – This concept combines two pull themes: everyone owns all their data and decides how it is used and how visible it is; data can be made anvailable to any service or provider based on data locker permissions.
- Single source of truth for data – In the pull era, data will never be duplicated.
Key Enabling Technologies
- On-line data locker – The on-line data locker precludes the need for wallets, paper files, multiple user accounts, bank accounts, and most of the information storage and retrieval technologies we use today.
- Digital Birth Certificate – Each manufactured object will have a unique documented identity that will follow it through its life and document its lifecycle. This information will be used for product development, reuse, and ecologically mindful disposal.
- RFID – Although RFID has not seen the adoption that Siegel would like, the attributes of RFID that make it important for the pull vision are the ability of any object to make itself known to a local or global network and enable two-way communication information about its status.
- Taxonomies – Taxonomies structure information in a machine-readable format and make it available for the various processes and flows in the pull paradigm. For example, Extensible Business Reporting Language (XBRL) is a taxonomy that standardizes the data contained in financial reports in order to allow universal interchange of the information. This structured data can then be presented in a standard financial report or any other desired format.
- Ontologies – On-line ontologies are sets of rules which support answering questions (rather than just searching for keywords). This semantic search functionality is key to pull because it allows more effective use of on-line information.
- Semantic search – Rather than relying on keyword matching, semantic search answers questions, making information more accessible and enabling true decision support.
- Unique identity - To enable many of the pull concepts, everything and everyone needs a unique identity.
The History of Information
Siegel traces the evolution of information generation and storage in this video from its beginnings in the earliest writing to the explosion of data fueled by internet technologies and media.
He frames the problem by saying that the way we’re currently using information is broken at the scale we’ve achieved. After a keyword search, we visit each page to see if the answer is there; search engines don’t know if the answer to our question is on a given page; search engines only return keyword hits and links; search engines must guess the meaning of the information on the pages. Similarly, it’s not possible to compare similar items on different websites.
The solution is the pull concept described in the book which is supported by the semantic (unambiguous) web.
Your Online Data Locker
Much of the pull vision is supported by the idea of a personal data locker which not only stores all the information you generate and collect, but can also intelligently act upon that information to make decisions.
Here Siegel describes his vision of the personal data locker, a cloud-based desktop which contains all our information and applications/services.
Agile projects rely on agile estimating and planning processes which answer the question: “What should we build and by when?” Answering this question requires first estimating (“how large is it?”) and scheduling (“when will it be done?”, “what can we deliver by then?). Agile Estimating and Planning covers planning challenges and goals, estimation, prioritizing features and backlogs, scheduling, monitoring, and communication. Mike Cohn presents a comprehensive handbook for agile estimating and planning that includes the rationale for the agile approach along with a point-by-point explanation of why traditional planning methods don’t work.
…planning is difficult. Teams often respond to this by going to one of two extremes: They either do no planning at all, or they put so much effort into their plans that they become convinced that the plans must be right.
Plans and schedules are required for a number of business imperatives: industry events, customer delivery dates, marketing campaigns, budget and resource availability, and downstream activities such as training. Although these pragmatic considerations drive the need for planning, Cohn says planning is primarily “a quest for value.” A planning team addresses “what should we build?” by considering features, resources, and schedules in an iterative and incremental manner. A good planning process supports finding the right combination of these three variables by reducing risk, reducing uncertainy, supporting better decision making, establishing trust, and conveying information. Cohn notes that the biggest risk on a project is not missing the schedule or overspending the budget, it is building the wrong product. Trust, another important quality of successful projects and teams, is built in agile projects through reliable estimates and frequent delivery.
A good plan as one that stakeholders find sufficiently reliable that the they can use it as a basis for making decisions.
Agile planning welcomes change based on learning and new information. Balancing the time and effort required for planning with the foreknowledge that the plan will change is a key to successful agile planning. “This means we need plans that are easily changed,” writes Cohn. It’s important to note that agile planning does not automatically lead to date changes. In agile planning, dates may change, features may change, or quality may change–all depending on decisions made in the planning process. To support these principles, agile planning is spread through the entire duration of the project rather than front-loaded at the beginning.
Features are the unit of customer value. Planning should, therefore, be at the level of features, not activities.
Traditional planning focuses on activities rather than features which shifts the focus away from customer value and introduces a host of issues. Dependencies between activities create cascading schedule delays and individual activities rarely finish early. Moreover, features are not developed in order of priority and uncertainty is masked by the presence of an elaborate written plan.
The Agile Way
Projects should be viewed as rapidly and reliably generating a flow of useful new capabilities and new knowledge, rather than just a series of steps. Projects generate two types of new knowledge: knowledge about the product and knowledge about the project.
The Agile Manifesto written in February 2001 has four key principles that define the agile approach:
- Individuals and interactions over processes and tools
- Working softwre over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Taken together, these value statements guide the way agile teams work:
- Work as one team
- Work in short iterations
- Deliver something each iteration
- Focus on business priorities
- Inspect and adapt
Agile teams have specific roles including product owner (responsible for product vision and prioritizing features), customer (person paying for the project or purchasing the software), user, developer, and manager. Agile teams work in short iterations of pre-defined duration and deliver working software (including features prioritized according to business value) at the end of each iteration. Three levels of planning ar used: release planning, iteration planning, and daily planning. Release planning focuses on the Product Owner’s conditions of satisfaction which are comprised of user stories, budget and schedule. Iteration conditions of satisfaction consist of user stories and acceptance tests.
In agile projects, the desired features are written as user stories which are then estimated for size. Estimates are typically in the form of “story points” that provide relative size. Story point completion is tracked for each iteration to determine velocity (story points per iteration). Once velocity is calculated, a duration can be derived (based on best case, worst case, and average case velocity). From there, a schedule can be constructed.
Cohn suggest four factors to take into consideration when prioritizing based on business value:
- Financial value of having the feature
- Cost of developing (and maintaining) the feature
- The amount and significance of learning and new knowledge created by developing the feature
- The amount of risk removed by developing the feature
When considering risk, Cohn uses a risk/value matrix and recommends delivering high-risk / high-value features first, followed by low-risk / high value, and finally low-risk / low-value. High-risk / Low-value features should be avoided.
Revenue can be broken down into new revenue, incremental revenue, retained revenue, and operational efficiencies.
Cohn uses the Kano model of customer satisfaction to give context for feature prioritization decisions. The Kano model has two axes: customer satisfaction (low to high) and feature presence (absent to fully implemented). Features which provide high satisfaction based on even a partial implementation are “exciters and delighters”. Features which do not provide a higher level of customer satisfaction even when fully implemented are “must-haves or mandatory”.
Release planning and iteration planning form the core of scheduling activities in the agile approach. Iteration plans contain taks and are estimated in story points or ideal days; release plans contain user stories and are estimated in ideal hours. Iteration plans usually span multiple iterations and last three to six months. Essentially, an agile team will iterate until the conditions of satisfaction for the release can be met.
The agile scheduling process consists of these steps: 1) determine conditions of satisfaction; 2) estimate the user stories; 3) select an iteration length; 4) estimate velocity; 5) prioritize user stories; and 6) select stories and release date.
Cohn has an interesting chapter on buffering for uncertainty which addresses the inevitable unknowns in any project. He illustrates creating schedule buffers, feature buffers, and a combined buffer. In projects where time is of the essence, a schedule buffer can be implemented. For feature-driven projects, a feature buffer is used. A combined feature and schedule buffer can provide a range inside which a release or delivery can be made.
There’s a lot of detail in the book–it’s meant for a team to read and discuss together. He covers planning for multiple teams which is an important consideration for large projects. Also, Cohn explains how to monitor release and iteration plans and communicate status. There’s a case study at the end which tells the story of an agile team working on a hypothetical software product. If you buy in to the agile approach and want a book with which to start right away, this is a great pick. It covers all the bases and provides the conceptual framework along the way.
An organization’s ability to learn, and translate that learning into action rapidly, is the ultimate competitive advantage. —Jack Welch
Agile and the Seven Deadly Sins of Project Management
Cohn gives a brief overview of the Agile method and then describes the seven deadly sins of project management (and how Agile addresses each):
- Gluttony – The desire to fix all dimensions of a project (scope, schedule, resources, and quality) which leads to impossible schedules and death marches. By timeboxing iterations and calculating velocity, Agile increases predictability. Since Agile iterations are fixed, the schedule is fixed and the focus is always on “what can we accomplish next?”
- Lust – An intense or unrestrained craving for features, all of which are critical. This results in lots of overtime and surprises. By developing features in priority order (forced stack ranking) Agile offers incremental gratification in two to four week increments. The team asks: “what is most important to do next?”
- Sloth - Failing to do high quality work at all times by testing quality at the end of the project. Sloth is characterized by instability during development, big delays, and unpredictable schedules. Agile/XP practices related to quality include: simple design, automated testing, test-driven development, continuous integration, pair programming, and refactoring.
- Opaqueness – Obscuring the progress, quality, or other attribute of a project which obviously leads to not knowing the true state of a project. Using the waterfall method, you have no idea if three months or three weeks is the right amount of time to schedule for testing. Agile addresses quality opaqueness by not letting bugs accumulate, using continuous integration, and avoiding the “90% done” syndrome by classifying features as either done or not done. Schedule opaqueness is handled via iterations that are timeboxed so teams get used to meeting deadlines. Because work is either done or not done, the release burndown chart shows real progress. Finally, scope opaqueness can be remedied by using actual velocity numbers to calculate best case, worst case, and average case velocity and predict how much work can be done in a give number of iterations.
- Pride – Believing we know everything needed to build the product. The causes of this are lack of stakeholder and user involvement which leads to failure to solicit feedback and failure to learn. Agile retrospectives, daily standup meetings, and engaging users with user stories are antidotes to this problem. Progressive refinement of user stories enables separating large stories into smaller, more specific ones.
- Wastefulness – Misuse of critical resources. This issue is experienced as loss of creativity, motivation, and time. It leads to delays and mailaise. Agile has several techniques to combat waste on projects: timeboxing iterations, daily standup meetings, iteration retrospectives, self-organizing teams, and spreading intensity out evenly.
- Myopia – Not seeing beyond your own work. The symptoms here are teams which don’t see the big picture and individuals who work only within their roles. This leads to unsuccessful products and delays. With Agile, planning is done at different levels (a release plan consisting of sprints) with cross-functional teams in order to provide context for everyone.
Agile Teams: Scope and Scale
In this video, Cohn discusses scaling Agile up to large teams–he starts with a 700 person team example. Cohn begins by saying that many Agile books can be read as describing “a lone team on a desert island”; however, Agile can scale up very well.
He says that in a large Agile project, there is no “one guy in charge”, rather, there is a Chief Product Owber who has a vision of where the product needs to go. Reporting to the Chief Product Owner are LIne Product Owners. For example, the Chief Product Owner could be responsible for Microsoft Office and the Line Product Owners are responsible for Excel, Word, and Power Point. The individual teams can coordinate work on their own and need three things: money, moral support, and guidance (from a Product Owner).
In addition to vertical Agile teams, he recommends horizontal teams; for example, server side developers and client side developers. The horizontal teams correspond to functional areas such as software engineering and are led by a role like VP of Development.
He concludes the interview by describing the Agile estimating and planning methodology–estimate softwrae in the way estimate in the real world. First, estimate the size and then derive the duration. Agile uses story points as relatively valid units to estimate size; velocity is then calculated at the end of each iteration as the number of points completed.
More on Agile planning:
To develop breakthrough products, product teams need to stop gathering requirements and listening to “the voice of the customer” and start focusing on “jobs to be done” and the metrics by which customers evaluate products and services. What Customers Want: Using Outcome-Driven Innovation to Create Breakthrough Products and Services presents three product development tenets: customers buy products and services to help them get jobs done; customers use a set of metrics (performance measures) to judge how well a job is getting done and a product performs; customer metrics make possible the systematic and predictable creation of breakthrough products and services.
The foundation of the method presented in this book is a ranking calculation based on importance and satisfaction ratings from customer surveys. All downstream product development decisions are based on the list of prioritized jobs to be done, outcomes, and constraints. Author Anthony Ulwick approaches innovation from a process perspective–identifying inputs and outputs and mapping the steps in order to optimize.
For Ulwick , “innovation is simply the process of figuring out ‘what customers want.’” Specifically, “companies need to figure out what jobs customers want to get done and how they measure success in getting a job done before they can determine what solutions customers want.” This presupposes that customers know what jobs they want to get done and can articulate it, which may not be possible when creating entirely new offerings.
In terms of innovation success, Ulwick’s fundamental assumption is that “by identifying the stages of innovation and eliminating the factors that introduce variability into the innovation process, companies can realize higher innovation success rates and more breakthrough products and services.” The reduction of variability in innovation is a contested issue. Many innovation leaders assert that high variability is exactly what produces the best results–it is not possible to optimize the innovation process.
Moving beyond the customer-driven paradigm
The customer-driven model does not work because, Ulwick says, “when companies gather customer requirements they do not know what types of inputs they need to obtain from the customer. Neither does the customer. Consequently, the customer offers his requirements in a language that is convenient to him, but unfortunately that language is not particularly convenient for the creation of breakthrough products.”
The remedy is for companies “to know, well in advance, what criteria customers are going to use to judge a product’s value and dutifully design a product that ensures those criteria are met.” However, “customers have these metrics in their minds, but they seldom articulate them, and companies rarely understand them. We call these metrics the customers’ desired outcomes.” Identification of the outcomes through requirement gathering interviews and ranking them through surveys is Ulwick’s preferred method of prioritization.
Choosing your innovation strategy (types of innovation)
The first step in Ulwick’s method is to select the appropriate innovation strategy by choosing between various types of innovation: product/service innovation (improvements to existing offerings), new market innovation (where no product exists to do the job), operational innovation (increasing efficiency within business operations), and disruptive innovation (new technology which disrupts a dominant business model with a good enough solution). It’s also important to consider all relevant customers (including the end user) and decide where in the value chain you will focus your efforts. Once the broad innovation target has been established, customer inputs can then be gathered.
Capturing jobs, outcomes, and constraints
The objective of requirements gathering is for the product team to understand what metrics customers use to determine value when getting a job done (#jtbd on Twitter). While gathering requirements, teams typically face challenges with defining what requirements are, believing that they are getting the right kind of information from customers, and, in the process, not getting the right kind of information.
When asked, customers frequently offer solutions, design specifications, needs, or benefit statements. Because customers are not technologists or engineers, their solution recommendations often do not address the job to be done. Likewise, specifications from customers may not yield a better product. Needs are usually imprecise and open to interpretation, making them difficult for the company to incorporate into a product or service. Similarly, benefit statements are ambiguous and not actionable.
Given these challenges, the product team must focus on identifying the jobs customers are trying to get done (tasks and activities), outcomes the customers want to achieve (metrics used to define successful execution), and constraints that might prevent adoption. To discover these three inputs, Ulwick recommends user interviews with interviewer restatement and clarification. This method produces a concise requirements document which is then used as the basis of customer surveys for ranking purposes.
Identifying where the market is underserved and overserved
The core of Ulwick’s method is prioritizing the opportunities (jobs and outcomes that are underserved). Ulwick uses surveys and an algorithm to rank the opportunities that have been discovered. This ordered list of opportunities is then used to determine the order of investment for product and service development.
Specifically, a survey containing jobs, outcomes, and constraints gathered from customer interviews should be given to a statistically valid representation of the target market. In the survey, participants should be asked to rate the importance and their satisfaction with each element.
For Ulwick, Opportunity = Importance + max (Importance – Satisfaction, 0). For example, if a job had an importance of 10 and a satisfaction of 3, its Opportunity score would be 10 + max (10-3,0) = 17. The max function ensures that Opportunity is never a negative value (effectively prioritizing importance in the equation).
The Opportunity score is the core metric for determine which jobs, outcomes, and constraints to pursue. A score of 15 or above represents a highly attractive opportunity while a score of 10 to 15 are attractive for some markets, and scores of less than 10 represent overserved jobs and outcomes. This mapping can indicate overserved markets which might be candidates for a disruptive innovation.
Market segments (groups who have unique sets of underserved or overserved outcomes) are then defined by aggregated opportunity groups. To identify market segments, collect customers’ desired outcomes, choose the segmentation criteria (outcomes with the most variance), conduct cluster analysis to identify the groupings, and then profile the clusters. According to Ulwick, this process will identify unique opportunities in mature markets, customer segments willing to pay more for enhanced solutions, and undesirable customer segments. Growth targets can be identified through the same means–outcomes that are underserved. Focusing marketing message development and communication campaigns on outcomes and jobs to be done will ensure benefits are well understood by customers.
Although the products and services that satisfy a job to be done or outcome change over time, the outcomes customers are interested in do not. When an outcome is satisfied by a product or service, companies must look to other outcomes to create value or to unsatisfied/underserved outcomes. Assuming that outcomes and jobs to be done are available and correctly identified, a company can use this model to predict value migration from underserved to overserved outcomes.
You can’t put into Excel how customers will respond to a new idea — Jeff Bezos
The outcome-driven process moves away from ambiguous and non-actionable benefits statements, solutions, specifications and needs to higher order elements (jobs to be done, outcomes, constraints). It has a solid foundation in understanding the goals and objectives of your customers, but is heavily dependent on requirements sessions and surveys which may lead to blindspots that might be better discovered by other means. The risk in predominantly analytic method is that customers may change their minds about satisfaction and importance when presented with the final solution. Also, customers may know what jobs they are trying to get done today, but may not know the jobs they will try to get done tomorrow (new technology can present us with entirely new sets of jobs to be done and outcomes).
In the video below, Ulwick describes his epiphany having worked on the IBM PC jr product: “if we could address the criteria that people use when judging [a product's] value, then we’d have winning products”.
In this excerpt, Ulwick begins his systematic approach to the innovation process by noting that there is typically not a shared definition of “innovation” or “customer needs” within companies (although both are perceived as critical for success).
Creating great products in an uncertain world requires changing the way you think about your customers, products, and development process. Subject To Change: Creating Great Products & Services for an Uncertain World: Adaptive Path on Design evolves these three aspects of product development. Approaching your customers as people rather than passive consumers provides a new view of opportunities. Considering the entire system and context in which a customer interacts with a product, rather that viewing a product a s standalone entity, enables greater value to be created. Using Agile methodologies, rather than a traditional Waterfall approach, enables a more sane, responsive, and adaptive way to bring products and services to your customers. Rather than trying to predict the future, these strategies create a closer relationship to the customer and market. This book provides the rationale, strategies, and tactical considerations for user experience centered product design.
To be uncertain is to be uncomfortable, but to be certain is to be ridiculous.
Adaptive Path co-authors Peter Merholz, Brandon Schauer, David Verba, and Todd Wilkens identify three organizational competencies essential to great product and service development: customer research, design, Agile technology implementation. These competencies help address the uncertain context that surrounds product and service development. Not only is there uncertainty in the marketplace, but the product design and development process itself is murky because “people are inconsistent, often inarticulate, and they challenge social and cultural boundaries in unexpected ways.” Comfort with uncertainty comes from a flexible approach grounded in a product vision and closeness to your customers. Instead of attempting to predict the future, it is better to be responsive and adaptable.
All that matters to customers is their experience.
The cornerstone of Subject To Change is the experience the end user has when interacting with your product or service. Focusing on the customer experience allows a closer relationship to customers and the ability to add more significant value than can be done through a more limited view. Because “humans invest nearly all of their experiences with meaning”, the product entire design team must have a shared understanding of the meanings that customer has assigned to the product or service experience. The authors observe that, “to stay viable, product categories require a quantum evolution that takes them beyond technology and features and on to the satisfaction of a customer experience.”
Experience strategies help your company to start designing from the outside in, i.e., from the perspective of those who will be using the product or service you’re providing. It’s an overarching plan that starts with the customer and works its way back through to your organization’s operations and infrastructure.
An experience strategy is much like Marty Cagan’s Product Principles, a statement or manifesto that guides the team. It’s a product’s North star and helps crystallize the end goal and decision making along the way.
Product development organizations have evolved from a technology focus (building what is possible or interesting) to a feature focus (building discrete features that encompass an end user benefit) to an experience focus (considering the entire context of use and resulting user experience). Getting closer to the customer and the meanings associated with a product provides a powerful context for design. This provides an outside-in perspective instead of the commonly used inside-out view that frequently fails to meet customers needs and desires. The product team must repeat to themselves: “we are not the target market” (unless they actually are).
The success of experience-focused products is contingent on everyone sharing an understanding of users and a vision of the experience because so many people play a role in delivering that experience.
Companies that make great products have changed their perspective on their customers over time. Initially, the people who used products and services were considered passive “consumers” or sheep-like beings who blindly follow advertising and marketing messages. This view evolved towards the commonly practiced “task / activity / preference” method in use in many product development methodologies where the end result is a feature. The user experience focus, however, uses motivations, behaviors, and meanings to understand, empathize with, and design for end customers. This view acknowledges that although people accomplish tasks and activities, what they really want is the experience or meaning associated with its performance and/or completion.
Although customer research can result in shelfware (“where good insights go to die”), it is successful when: 1) it is acknowledged as an organizational competency; and 2) it delivers outcomes that are actionable and durable (the findings have a life outside the initial research presentation or document). There’s no point in undertaking research if the end result does not have longevity. Design research “helps establish the constraints and opportunities that make great design possible.”
The Design Competency
Good design is humanistic (based in a empathetic understanding of the end user), generative (able to envision multiple alternatives), and based on making decisions (based on design constraints, business objectives, and strategy). Design is not “throwing out as many ideas as possible”. Much of the book covers examples of good and bad (not meeting anyone’s needs) design.
Begin with the experience you want to design for, and then–and only then–identify the components that will deliver it.
You have to recognize that a system will degrade, and make it such that such entropy doesn’t shatter the entire user experience.
The authors say that “the system is the product” and give several examples in the book of successful products that are built as part of a broader value system. The iPod/iTunes/iTune store combination illustrates how an entire ecosystem contributes to a positive experience and partitions outcomes (manage, purchase, listen) to various elements of the whole.
Many organizations are good at building technology, but “the ability to create a new technology isn’t synonymous with the ability to craft a desirable customer experience” because the focus and competencies are different. Elements of the final system can only be created after the ultimate experience has been envisioned.
Designing standalone “products” limits the value that can be created. Product teams should consider the entire system that must be in place to support and create the desired experience. Focusing too much on the product itself is problematic because “design can and will fail when it’s practiced outside of the context of systems and strategy.” The context of use provides design goals and constraints that are critical for success. In order to ensure that everyone in the company understands the desired experience, a clear strategy needs to be in place to help align efforts and assist in decision making.
Over-engineering is the flip-side risk to system-based design thinking. Trying to design each and every element of an environment can lead to a highly brittle creation that breaks when any of its parts does not function as designed.
Much like Stewart Brand in How Buildings Learn, the authors point out that design should be flexible enough to accommodate future uses and users. Good design carefully examines constraints and takes into account future opportunities.
Ideas are cheap, cheap, cheap; we can think of so many. All too often, though, our organizations treat them as tender, scarce, and special.
Ideas live in Power Point presentations, where they are treated like descriptions on the sealed box of a toy. Everyone reads the packaging but dreams up a different idea of the product or experience inside.
Because “ideas are neither scarce nor fragile,” they do not need to be protected and hidden from view. Bringing ideas out into the harsh light of day for team examination allows assumptions to be tested and refinements to occur before investments are made. Handling ideas requires a different skill set than daily operations.
Many companies are good at “managing” (optimization, process improvement, efficiency), but struggle with “doing” (innovation, execution) because consistency, precision, and repetition do not translate into the variation, failure, and serendipity required for great products. Product development usually begins in a hazy environment where “anticipation far exceeds insight, plans seem arbitrary, no amount of research is enough, and uncertainty runs rampant.” Applying optimization won’t help at that stage.
In an environment where exploration leading to a dead end is viewed as an expense to be reduced, true innovation is difficult.
The Agile approach is the answer to the question “what are you doing to harness change to create greater value?” and combines highly iterative processes, bringing customers into the development process, creating smaller work groups, and in-line testing. Adopting the Agile perspective allows product development teams to decrease costs through small batch size, save time by creating less documentation, building essential feature sets based on continuous prioritization. (Here’s a great description of the Scrum product backlog, an essential component of Agile development).
The Long Wow
Are you building a platform that can create wow moments over the long haul?
The Long Wow is one of the outcomes of a customer experience strategy. It’s a way of thinking about your product or service in the context of customer touch points and opportunities for delight. The Long Wow is created by applying several strategies: 1) know your customer touch points and understand your platform for delivery; 2) draw from areas of continual unmet needs; 3) evolve repeatable processes for delivering wow moments; and 4) stage and plan the wow experiences. In the video below, Verba and Schauer advise to “pick points in time when your organization does things better than anyone else and focus on those.” Understanding your customers desires and context will allow the product team to “organize a pipeline of wow moments that can be introduced through your pallet of touch points over time.” The element of time is important because it is over multiple positive experiences that strong relationships are built.
Here’s a video of two of the co-authors, David Verba and Brandon Schauer presenting “Subject to Change” to a GoogleTalk audience. Centered on the principle “the experience is the product”, they talk is divided into four segments: 1) focus on experience; 2) focus on the lives of customers; 3) embrace the complexity; and 4) engage in design as an activity.
Inspired: How To Create Products Customers Love by Marty Cagan is a treasure trove of direct and immediately useful product management techniques and strategies. The book is organized in three categories: People, Process, and Product. Each category contains short chapters which are written in a clear style that comes from Cagan’s passion about the topic and his extensive experience in product development. Inspired is written for software development teams, specifically, people who are responsible for defining products and bringing them to market. The book is not aimed at non-software products, but there are many topics that remain valuable across industries. Chapters span the tactical to the strategic making it a great read cover-to-cover and a go-to reference for your physical or virtual bookshelf.
It doesn’t matter how great your engineering organization is if the product manager doesn’t give engineers something valuable, usable, and feasible to build.
In discussing roles and responsibilities, Cagan says “the root cause of wasted releases can most often be traced to poor definition of the role of product manager in a company and inadequate training of the people chosen for this role.” There are several common root causes for this: marketing-driven product development that skips the hard choices and discovery provided by product management; two people playing the product management role, one responsible for “high level” requirements and one for “low level” requirements; one person playing two roles trying to cover product marketing and product management. Cagan’s cure for this set of issues is to clearly define the product manager role as being the person defining the product and the product marketing manager as the person who tells the world about it. In addition to product marketing, Cagan also outlines the differences between product management and project management, user experience, and software engineering all of which frequently overlap with product management.
There are some people out there who just love products–they live, eat, and breathe them.
The book covers recruiting, selecting and managing product managers (not something that is discussed in many product management books). The key ingredient is, of course, passion. Customer empathy and focus are also key attributes of great product managers. Cagan believes that 80% of product management skills are transferable across industries. He says domain expertise, although often valuable, can detract from curiosity and the ability to validate and question assumptions.
I have found that the most valuable experience is not what you learn about some product domain or technology…but rather what you’ve learned about the process of creating great products, leading a product team, and managing growth.
In the context of managing product managers, Cagan discusses the role of the VP of Product Development (a critical role responsible for managing the team and defining strategy) and metrics (he suggests using Net Promoter Score). He prefers to see the product organization on its own (rather than reporting in to marketing or engineering) except in the case of large organizations where it might be housed within a business unit.
Cagan favors a Product Opportunity Assessment instead of a traditional Marketing Requirements Document. To define the opportunity, a product manager must answer these questions along with a “go-no-go” evaluation:
Value proposition: What problem does the product solve?
Target market: Who specifically is the customer?
Market Size: How large is the opportunity in terms of buyers and revenue?
Metrics/Revenue: How will success be measured?
Competition: How are customers solving this problem today?
Differentiation: Why are we best positioned to go after this opportunity?
Market Window: Why do it now?
Go-To-Market: How will the product get to its customers?
Requirements: What are critical success factors?
When working through the assessment, Cagan notes “all too often what happens is that a product manager combines the problem to be solved with the solution, and when they run into difficulties with the particular solution they are pursuing, they abandon the opportunity.”
Some key product development techniques that Cagan outlines are:
Product Discovery – This initial phase allows you to determine whether there are real customers who care enough about the problem to pay for its solution. Then, you must find a solution that is “valuable, usable, and feasible.”
Product Principles – A set of high level guiding concepts that reinforce the product’s DNA and helps make design decisions.
Product Council – A group of stakeholders responsible for internal alignment around product definition. This group should review products as they go through each lifecycle milestone.
Charter User Programs – Finding early customers that will help you validate product definition, become early adopters, and eventually serve as references.
Personas – Customer archetypes which help the team focus and make decisions.
Prototype – Rather than create a traditional product spec (which is rarely complete or read by anyone), Cagan likes to use high fidelity prototypes to validate assumptions with customers and provide the engineering team with a model for implementation. Some documentation will still be required, but the core of the product definition should come from the prototype. This also allows the user experience to be designed before building the product commences.
Cagan includes chapters on product validation and prototype testing, which, although not as articulated as Four Steps to the Epiphany and The Lean Startup, is a break from traditional product development methodologies (which are mostly based on the Waterfall model). He diagnoses the “ready, fire, aim” product development approach that occurs in many startup environments and, like Steve Blank and Eric Ries, reinforces the importance of deliberate discovery and validation. Cagan also includes recommendations for “intrapreneurs” (people in large companies who are working on startup or innovation efforts).
Cagan finds three product development lessons from Apple’s success that can be applied to any product:
- The hardware serves the software
- The software serves the user experience
- The user experience serves the emotion
This framework puts functional, technical, and experiential components in the service of the emotion that will be felt by the end user. When all three act in concert, the entire platform supports a powerful result.
Cagan says “great product managers combine what is desirable with what is now just possible” to create compelling offerings. The trick is finding the sweet spot between unfulfilled need and technological feasibility.
The book describes success factors for consumer internet products, enterprise products, and platform products, each of which have unique characteristics. Usability, scalability, and viral marketing are keys for consumer internet products while charter user programs, sales channel design, and integration are important to enterprise products. Platforms require balancing the needs and benefits of application providers, developers, and end-users.
The book concludes with a best practices section that has some great product management guidance. Here are my favorites:
It is shocking to me how many product teams think they can come up with great products without talking to users and customers.
Product management is all about making choices…
The primary responsibility of the product manager is to discover a product that is valuable, usable and feasible.
Improving a product is not about adding features that customers request; it is about analyzing the product’s actual use, and then relentlessly driving the product to improve the key metrics.
Here’s a video of Cagan explaining prototyping:
In this video, he discusses product discovery:
This book weaves together three themes: product complexity, weaknesses of personal computers, and the concept of an information appliance. Norman’s focus is the personal computer as it was available in 1998 when the book was written. However, many of his observations and predictions have proven to be on the mark from the 2012 vantage point. He uses many early 20th century technologies as examples of disruptive patterns, standards adoption and poor usability design. Human-centered design figures prominently in the book as an antidote to the Swiss-Army knife approach that has led to the the personal computer as describes in the book.
Norman devotes several chapters to dissecting the weak points of personal computers: complexity, general use features, and a business model based on planned obsolescence. He also points out that the traditional graphical user interface, which was initially developed to surface all available functions and options, cannot scale to accommodate the massively complex software systems which are now being produced.
In The Invisible Computer: Why Good Products Can Fail, the Personal Computer Is So Complex, and Information Appliances Are the Solution, Donald O. Norman describes his ideal information technology product: single purpose, highly interconnected, simple, easy to use, and a pleasure to own. His vision contains parts of ubiquitous computing and current mobile technology.
Technology Adoption Lifecycle
As long as the technology’s performance, reliability, and cost fall below customer needs, the market is dominated by early adopters…but the vast majority of customers are late adopters. They hold off until the technology has proven itself, and then they insist upon convenience, good user experience, and value.
Norman uses the Technology Adoption Life cycle to illustrate the mistakes companies make as they introduce technology products to the market. Frequently, products are sold and marketed using the wrong emphasis which is out of synch with the life cycle phase for the technology. Norman blends Clayton Christensen’s performance curve with Geoffrey Moore’s Technology Adoption Life cycle to indicate how products should be brought to market. In the early stages of the technology life cycle, early adopters are looking for a solution to a specific problem and anything that helps them will be sufficient. As the technology begins to get traction in the market, explaining the benefits and creating effective messages becomes more important so marketing becomes a primary activity. Eventually, as the product matures and hits the mainstream market, usability is at a premium, and then user experience design skills join technology and marketing to form the three legs of the stool. He argues that information appliances are more at home in the consumer marketplace than they are in the high-technology marketplace.
The principle here is “Know your customer. Being first, being best, and even being right do not matter; what matters is what the customers think.” For infrastructure technologies, something Norman addresses several times in the book, n it’s just important be be good enough.
Analog versus Digital
The dilemma facing us is the horrible mismatch between the requirements of these human-built machines and human capabilities. Machines are mechanical, we are biological. Machines are rigid and require great precision and accuracy of control. We are compliant. We tolerate and huge amounts of ambiguity and uncertainty, very little precision and accuracy.
The mismatch between the way information is processed by computers and the way it is processed by humans is for Norman the source of much of the poor user experience design. He seeks a complementary interaction between the two fundamentally different systems. Today, he writes, “the designers determine the needs of the technology and then ask people to conform to those needs.” This mismatch is the source of much frustration with technology products.
Easy and Difficult
Much of the book is devoted to ease of use and exploring how to make technology fit well in our lives.
A feeling of control, a good conceptual model, and knowledge of what is happening are all critical to ease of use. The controls must be recognizable, it must be easy to remember their function and operation, and they must provide immediate and continual feedback about the state of the system.
When is something difficult? When the controls and actions seem arbitrary, when the system can get itself into peculiar states, peculiar in the sense that the person using it does not know what it it doing, how it got there, and how to recover.
Understanding a technology is paramount for its usability. Norman writes that “understanding comes about when the system presents a clear conceptual model of itself, making the possible actions apparent.” Using our natural pattern-seeking behavior in new situations, “we look for familiar patterns, we look for any signs that might direct us, and we try to make sense of whatever happens.”
Disrupting the Personal Computer
Norman sees information appliances as the antithesis to personal computers and as a true disruptive technology. Computer manufacturers and companies within the PC ecosystem find it hard to turn away from their core products and business models in favor of a new approach. However, the personal computer industry, at the time of this book’s writing, was in its mature phase and the focus on technological firepower and feature-rich products needed to give way to simplicity and user centered design.
Information appliances should be thought of as systems, not isolated devices. The goal is to provide solutions for the consumer, not just electronic gadgets. The physical devices is only piece of the entire story. The successful business will provide all the pieces. Those pieces include consumables, content, and services.
Norman effectively bases his information appliances on “jobs to be done“, Clayton Christensen’s fundamental principle of product and service development. We don’t want to do word processing, or work with databases or spreadsheets, we want to write letters, print pictures, or find answers to financial questions. Norman’s ultimate design aesthetic is for infrastructure (technology) to remain invisible, or at least in the background. The task, or job, that the person wants to do should be in the foreground of the product. A Swiss Army knife symbolizes the product that tries to do too much and, in the process, ends up doing nothing well. Norman acknowledges the tradeoffs between the convenience of a multi-purpose product and the power of a single-purpose product.
Information Appliances are special-purpose products which are used for single “jobs to be done”; for example, a camera, digital music player, or MIDI instrument. Examples from healthcare include home medical devices such as specific blood test units, heart monitors, and breath analyzers. Other possibilities include automobile guidance systems and home finance centers for paying bills, reviewing finances, and paying taxes.
An important attribute of Information Appliances is the ability to communicate with other Information Appliances. Applications on personal computers are valuable because they can create more value by exchanging information between one another and transforming inputs. Information Appliances such as digital musical instruments can use standards like MIDI to create a more valuable network than singular, self-enclosed systems.
Norman illustrates the invisibility of technology principle with the history of automobile and electric motors. In early cars, the engine interface was highly exposed and required several adjustments (spark, choke, crank) in order to start. Now, automobile engines can be started literally by pressing a button. Likewise, electric motors are present in many common devices, but their presence is not explicit–they are effectively hidden. Norman contrasts these technologies with personal computers which expose an enormous amount of their complexity to the user and demand a high level of expertise to operate.
Norman outlines three design principles for Information Appliances:
1. Simplicity: The complexity of the appliance is that of the task, not the tool. The technology is invisible.
2. Versatility: Appliances are designed to allow and encourage novel, creative interactions.
3. Pleasurability: Products should be pleasurable, fun, enjoyable. A joy to use, a joy to own.
The power of specialized information appliances comes from their ability to be interconnected. Information can be exchanged between them and they can be combined to perform more powerful tasks.
So long as the personal computer industry is in a mature phase of its life cycle, but continues to produce products as if it was in its early stages, it is ripe for disruption by single-purpose information appliances. Usability problems with personal computers arise not only from this mismatch in needs relative to life cycle position, but also from organizational and structural issues in the companies which produce them. Norman wants to bring human centered design to these products and push the technology to the background. He devotes an entire chapter to several organizational approaches for injecting better product design into a company’s DNA.
Steve Blank‘s book, The Four Steps to the Epiphany, initiated the Customer Development revolution by identifying patterns of success for startups. Blank says he was inspired to write the book when he realized there were “repeatable patterns of business behavior that could explain the heretofore unexplainable.” He believes product development processes as practiced by many companies and teams are destined to fail because they are focused on activities “inside the building” instead of getting out and understanding customer needs. Startups frequently focus on producing a product and neglect developing a validated understanding of their customer, market, and sales roadmap. Customer Development puts customer understanding and validation on equal footing with traditional product development processes and ensures that when the product is ready, customers have been identified, and involved and are ready to buy.
Companies need a parallel process to Product Development; one dedicated to bringing customers and their needs head-first into the new product introduction process–before the product is ever launched or shipped
Blank begins by discussing the familiar product development process used by many companies:
He points out that customers are not represented prominently in this model even though the greatest risk to most startups and product development efforts is in the development of customers and markets, not new products. The lack of customers and a solid business model is what causes most entrepreneurial efforts to fail. Customer Development remedies this by constructing and validating customer need and the financial model as part of the overall new offering development process. “Getting outside the building” to meet real customers and test your hypotheses are the building blocks for success.
Learning and discovering who a company’s initial customers will be, requires a separate and distinct process from product development.
Another problem with this model is that the focus is on the launch of the product rather than the acquisition of the first customers. If you do not understand exactly who you are selling to and why they would buy from you, having a product is not sufficient for success. Similarly, there is an emphasis on execution rather than learning and discovery. In the early days of a new enterprise, meeting and establishing relationships with future customers is a critical activity that is distinct from effectively producing a product or service.
The traditional product development model also does include have meaningful sales, marketing, and business development metrics. Significant milestones related to finding customers, developing the market, and validating the business model are not included in the traditional product development model.
Blank’s Customer Development model consists of four iterative processes:
- Customer Discovery – who are the customers for your product or service? is the problem you are solving important to them?
- Customer Validation – proving you have found your customers and market by building repeatable sales roadmaps and playbooks that will be used by field sales and marketing teams
- Customer Creation – creating and funneling end-customer demand into the company’s sales channel
- Company Building – the point at which the company transitions from informal learn and discover mode to functionally specialized groups (e.g., sales, marketing, business development)
The Customer Discovery phase consists of stating and testing six core hypotheses: product, customer problem, distribution & pricing, demand creation, market type, and competition. This is done through successive customer visits and conversations with your advisory board. Blank stresses that the goal is to develop “a product for the few, not the many”. Therefore, understanding all the needs of all your possible customers and identifying all possible features and benefits is not required.
A startup should focus its efforts on providing a product for an early set of customers who buy into the startup’s vision. Blank calls these customers “earlyvangelists” because they are not only enthusiastic and vocal, but also willing to pay. Earlyvangelists have a problem, understand they have a problem, are actively searching for a solution and have a timetable for finding a solution, have put together a piecemeal solution, and have or can acquire budget to solve the problem. It is by working with these early customers that the team will get the feedback necessary to improve the product or service.
The purpose of Customer Discovery is to identify those key visionary customers, understand their needs, and verify your product solves a problem they are willing to pay to have solved–or not.
Instead of asking customers what they need, Blank advocates identifying customers for what you are already creating. As the Product Development team is starting the process of building the product, the Customer Development team should be quickly catching up by increasing their customer knowledge so that by the time the product ships, there are already customers. The first version of the product should be “good enough for our first paying customers.”
Throughout the Customer Discovery phase, a detailed set of questions about the customer are being answered. These include identifying decision makers, their influencers, and the financial metrics by which they evaluate success. Specific demand creation strategies are also tested–how exactly will you communicate your offer to your customers? Also, hypotheses about the market and competitive situation are tested against reality to ensure the startup understands the environment it is entering.
The Customer Validation step “prepares the company for its first attempt at selling a product” by articulating the value proposition, preparing sales collateral, developing a distribution channel plan, and hiring a “sales closer”. Each of these deliverables relies on a the detailed customer and buyer insights that were identified in previous phases of the process. Here, sales efforts are focused on the first set of “earlyvangelists” in order to get feedback for product development. The goals of the Customer Validation step are sales readiness, sales to the “earlyvangelists”, positioning development, and verification of the hypotheses from the Customer Discovery phase.
In the chapter on Customer Validation, Blank provides detailed sales roadmap advice including how to identify decision makers, influencers, and access points within the organization. There are sample roadmaps which identify specific strategies for selling to enterprise customers.
The Customer Creation phase is founded on four building blocks: year one marketing objectives, company and product positioning, company and product launch plan, and demand creation plan. This phase culminates in the launch of the company and/or product. After identifying customers and learning about them, Customer Creation creates the strategies that will be used to reach more customers on a repeatable basis. Blank puts the heavy marketing spend after acquisition of the first set of customers to decrease the risk of burning up its cash too early in the cycle before it has achieved sufficient learning about its customers.
Finally, the Company Building phase involves moving from “earlyvangelists” to mainstream customers and, in the process, building internal culture, processes, and organizational structure.
The Four Steps to the Epiphany offers a detailed set of flowcharts and processes for each of the four phases. The book contains detailed checklists and activity descriptions that walk you through all the phases. Blank also includes various case studies from real startups to introduce the phases. Although it is very detailed, Blank adds a lot of real-world examples and commentary that make the Customer Development story memorable.