Product Management

Customer-first Design Thinking

To start, let’s explore the activities of leading companies positioned at the forefront of design and product development. In particular, the concept of user-centered design through an exploration of design thinking to illustrate the early stages of the product process, from empathetic research to ideation and prototyping.

Product teams must create with the customer experience in mind. One of a team’s biggest weaknesses is their own hubris. Someone has a “great idea,” and the team starts sprinting forward without adequately assessing if customers actually want it.  In some cases, leaders receive data that their product doesn’t fit a user need and defend their genius often falling back to the Steve Jobs quote:

“A lot of times, people don’t know what they want until you show it to them.”

— Steve Jobs

That may pass if you’re the CEO of Apple. Otherwise,  there are bosses, board members, and investors that need validation before spending millions to build a product.

Products built using a customer-first mindset are most likely to receive support and funding inside a firm. However, if an organization isn’t built from the ground up with a customer focus, it’s difficult to break out of activities that have provided value in the past. Companies can’t just flip a switch and become Amazon. Amazon was born with an obsessive customer focus, and it shows. The company has been able to repeatedly enter and dominate markets unrelated to their original product — physical book sales.

For companies not familiar with customer-focused methods, frameworks exist to provide structure and guidance towards creating customer-focused products. Design thinking, a process with a vibrant community and thorough documentation, is a fundamental method.

Lean Versus Design Thinking

When developing a product, people tend to stick to a single school of thought. As of late, these schools have been dominated by Lean Startup and design thinking.

These paradigms emerged from a need to systematically develop products at scale. However, while they are great in theory, direct application to product development is difficult.

Every product is subject to different circumstances from both the consumer perspective and the organization perspective. Situations can arise in which it would be detrimental — or just plain impossible — to follow a set methodology. Instead,  product development works best when a product leader can stay flexible and adapt to unforeseen changes.

This article investigates these leading paradigms so you know when to use them, and perhaps more importantly, when not to use them.

Review: Lean Startup

Principles from Eric Ries’s Lean Startup website.

Entrepreneurs are Everywhere
You don’t have to work in a garage to be in a startup.

Entrepreneurship is Management
A startup is an institution, not just a product, so it requires management, a new kind of management specifically geared to its context.

Validated Learning
Startups exist not to make stuff, make money, or serve customers. They exist to learn how to build a sustainable business. This learning can be validated scientifically, by running experiments that allow us to test each element of our vision.

Innovation Accounting
To improve entrepreneurial outcomes, and to hold entrepreneurs accountable, we need to focus on the boring stuff: how to measure progress, how to setup milestones, how to prioritize work. This requires a new kind of accounting, specific to startups.

Build-Measure-Learn
The fundamental activity of a startup is to turn ideas into products, measure how customers respond, and then learn whether to pivot or persevere. All successful startup processes should be geared to accelerate that feedback loop.

— Eric Reis on The Lean Startup website

For more on The Lean Startup, see our review and summary of Eric Ries’ book.

Review: Design Thinking

Steps from Stanford’s dSchool:

Empathize

Empathy is the centerpiece of a human-centered design process. The Empathize mode is the work you do to understand people, within the context of your design challenge. It is your effort to understand the way they do things and why, their physical and emotional needs, how they think about world, and what is meaningful to them.

Define

The Define mode of the design process is all about bringing clarity and focus to the design space. It is your chance, and responsibility, as a design thinker to define the challenge you are taking on, based on what you have learned about your user and about the context. After becoming an instant-expert on the subject and gaining invaluable empathy for the person you are designing for, this stage is about making sense of the widespread information you have gathered.

Ideate

Ideate is the mode of the design process in which you concentrate on idea generation. Mentally it represents a process of “going wide” in terms of concepts and outcomes. Ideation provides both the fuel and also the source material for building prototypes and getting innovative solutions into the hands of your users.

Prototype

The Prototype mode is the iterative generation of artifacts intended to answer questions that get you closer to your final solution. In the early stages of a project that question may be broad – such as “do my users enjoy cooking in a competitive manner?” In these early stages, you should create low-resolution prototypes that are quick and cheap to make (think minutes and cents) but can elicit useful feedback from users and colleagues. In later stages both your prototype and question may get a little more refined. For example, you may create a later stage prototype for the cooking project that aims to find out: “do my users enjoy cooking with voice commands or visual commands”.

Test

The Test mode is when you solicit feedback, about the prototypes you have created, from your users and have another opportunity to gain empathy for the people you are designing for. Testing is another opportunity to understand your user, but unlike your initial empathy mode, you have now likely done more framing of the problem and created prototypes to test. Both these things tend to focus the interaction with users, but don’t reduce your “testing” work to asking whether or not people like your solution. Instead, continue to ask “Why?”, and focus on what you can learn about the person and the problem as well as your potential solutions.

Where These Paradigms Succeed:

Lean Startup and design thinking excel in one key area: they help organizations deal with ambiguity. When organizations are building products, they are going in blind. They might have an idea of a product and they might have an existing platform, but they’re clueless when it comes to what the user wants.

True product innovation comes from deeply understanding the customer. And that’s why these processes were created. However, followers of these methodologies often betray their original intents. Instead of customer focus, lean and design thinking followers recite “fail fast.” Rather than deeply understanding pain points, practitioners throw MVP after MVP in the customer’s face, waiting for something to stick.  At large corporations, in particular, this haphazard approach is a great way for innovation efforts to be cut short.

Finding Something that Works for Your Organization

The most surefire way to ensure product success is to arm yourself with the most robust information available about your core and competition, find out where your customer is dissatisfied, and then build a team seeded with experts in your customer’s pain point. As Jeff Bezos wrote in his 2016 letter to shareholders:

There are many advantages to a customer-centric approach, but here’s the big one: customers are always beautifully, wonderfully dissatisfied, even when they report being happy and business is great. Even when they don’t yet know it, customers want something better, and your desire to delight customers will drive you to invent on their behalf.

— Jeff Bezos

Note: We’ve built a research framework to guide you through research that can be invaluable when building products as well as innovation strategies. For more, see our innovation strategy guide.

Use these methodologies to understand the basics of customer focus and production development. These paradigms were built by brilliant product thinkers and they provide the structure that allows product people to start poking around and investigating the actual problem.

But despite what some Lean Startup or design thinking evangelists may have you believe, these methodologies aren’t foolproof ways to save the world — let alone build solid products. Budgets, timelines, and politics tend to poke holes in the once-clear steps outlined in these paradigms. To best prepare your product for success, pull from these frameworks but ultimately create a new path based on your unique circumstances.

Consider product development examples from some industry leaders:

Each company pulls from these common paradigms, but they aren’t followed religiously. Such a following blurs the true focus of building a product.

Lean Startup for Experimentation & Exploration

Design thinking and Lean Startup have a lot in common: they both are focused on creating products that people love, they both are customer-focused, and they both derive much of their strength from a feedback loop between building and testing.

However, these processes work the best when applied to different stages in the innovation and/or product development funnel.  After countless discussions, ideation sessions, prototypes, and rounds of user feedback facilitated by design thinking, you come to a point where you have decided to move forward and bring the product to market. However, the product will still be far from maturity. Products must evolve and grow with users to eventually reach product market fit. This is often pursued by following Lean Startup principles.

As illustrated by Board of Innovation, below, design thinking is closely aligned with the problem space and does a great job of understanding the user, while Lean Startup is much more focused on rapid implementation and market exploration. Further clarified by Steve Glaveski, founder of Collective Campus,  “The lean startup is used to turn these proposed solutions into business models, underpinned by assumptions that are rapidly tested with actual customers to separate truth from fiction, learn and iterate towards product market fit.”

Source: Board of Innovation, 2017

Expand

We outline, here, some of the key concepts of Lean Startup and how they can help firms bring new products to market.

Minimum Viable Products (MVPs)

MVPs build on the testing principles outlined in design thinking. The MVP concept has existed in varying forms for years but was popularized by Eric Ries in a set of principles set out in his book, The Lean Startup. Ries defines MVP as follows:

“the minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.”

This is a crucial concept in new product development.  Whether in a startup or corporate environment, genuinely innovative products often see limited funding.  Fast, low-cost proof of concept techniques like MVPs provide stakeholders the validation they need while providing information about your customer.

For more on The Lean Startup, check out our review and summary of  Ries’ book.

Getting Over “It Must Be Perfect” Syndrome

For any involved engineer or product manager, putting out an early, less than perfect product can be difficult. At this point in the development phase, there likely has been countless customer interviews that have contributed to a growing list of desired product features.  MVPs push teams to distill that list into action. This commonly sparks an internal conflict within product teams: “What if the customer doesn’t get it? We need to include everything. Don’t they need to understand the entire vision?”

The purpose of the MVP, according to Innovation and Entrepreneurship Professor Steve Blank,  is to reduce wasted development costs and to get the product into the hands of visionary customers as soon as possible. It’s with these visionary customers in mind that the minimum feature set should be developed.

“Most customers will not want a product with a minimal feature set. In fact, the majority of customers will hate it.  So why do it? Because you are selling the first version of your product to Earlyvangelists.”

— Steve Blank, 2010

This set of customers, the “earlyvangelists,” will carry the product through the early iterations of development. The product won’t please everyone. The focus must be on the early evangelists that drive adoption and provide early revenue. This core group, who believe in the product vision, will act as blinders as feature requests start piling up.

Further reading on MVPs:

Prototyping

“Good prototypes don’t just communicate—they persuade.” 

— Tom Kelly, 2010

According to Innovation Management, prototyping has three important advantages:

“Prototyping makes a concept tangible. One can use all senses to design the proposed concept. It allows thinking with one’s hands; prototyping allows us to see if and how the various elements of the solution work together. It enforces consistency and completeness, and prototyping triggers concrete and pointed feedback.”

Adam Richardson in the Harvard Business Review says, “It’s always good practice to test early and often with rough prototypes, whether they are paper-based, 3D-printed, or simple wireframes of a user interface. These methods let you answer the fundamental questions early and cheaply — before you’ve locked yourself into a design direction.”

Prototyping, more than anything, validates ideas. According to Madhavan Ramanujam and George Tacke writing for the Harvard Business Review, Porsche succeeded in product innovation by designing the Cayenne around what they knew customers valued and what consumers were willing to pay. In contrast, Fiat Chrysler designed the Dart believing it could determine “value” in a vacuum, and the company left price as the last consideration. It was the year’s second-biggest product failure.

Two factors are present in a successful product: a high level of product usability and customer willingness to pay. Criteria for validation can be formed from the successes and failures of customer relations to previous products.

According to Ramanujam and Tacke, a flawed innovation process and flawed prototyping are the primary reasons that 72 percent of new products fail. Companies such as Porsche, Proctor & Gamble, and Swarovski crystal have a far lower failure rate.

How do they do this? They have a willingness-to-pay discussion with customers early in the product design process. In doing so, these companies receive feedback from target customers before they commit to substantial engineering, manufacturing, and marketing investments. This drastically reduces the possibility of product failure.

Prototyping is so important because consumers like to see and feel products to gauge their usability. According to Moe Kelly writing for the Harvard Business Review, “Usability is the second major killer of new products and services, and the bar is getting ever higher for what makes a great user experience. People will compare your product against the best things they’ve experienced, not just competitive products in its category. If it has a screen, people will touch it and expect familiar swipe functionality. If it has search functionality, they’ll expect it to auto-fill the most likely results. When they take it out of the box, they will expect to just plug it in or turn it on and have it work.”

Prototyping also allows for iterations in product development. If a prototype fails, what has been learned can be applied to the next product. According to Tom Agan in the Harvard Business Review, learning from mistakes has the greatest impact on increasing revenues from new products – that is, if a systematic review is undertaken that captures the lessons learned.

When it comes to deciding whether to modify or kill a product, Kelly suggests conducting a product evaluation that measures “hard” factors like features, costs, and capabilities, and soft factors, for example, installation, out-of-box experience, usability, aesthetics, and brand value.

Rapid Prototyping

“If you can’t point to the specific and glaring need you are solving for, something people care about and will pay to have solved, then kill the product and start over.” 

— Moe Kelley, 2015

Given the speed of modern business, many firms look for options to speed up their product cycles and reduce time to market. Enter rapid prototyping. Rapid prototyping offers a process for taking an idea and turning it into something of meaningful value. Whether your idea can come to fruition through a digital-only experience, a physical object, or a combination of the two, rapid prototyping allows you to quickly create, test, and evolve to a finished product, meeting the needs of your intended market.

 Julie Murat, bridgeforbillions.org via Quora

Expand

3D Printing

For physical products, 3D printing technology has greatly improved prototyping. Because of its speed and ability to produce highly complex forms, 3D printing is having a major impact on the efficiency and quality with which a company can prototype. Tweaking a 3D printer to refine a prototype is much cheaper than resetting factory tools and machines.

According to Fast Company, iterating on five or more possible solutions was the most effective way to launch a new product, beating out the traditional approach of identifying three good options, analyzing them, and choosing one to move forward. This approach also beat out the Lean Startup approach–taking a best guess, piloting it, and then pivoting based on what works. The iterations approach is 50 percent more likely to succeed.

According to Nathan Furr and Jeff Dyer in HBR, “innovators use four types of prototypes: theoretical prototypes, virtual prototypes (or pretend-o-types), minimum viable products, and finally the minimum awesome product, in that order, to reduce their risks and quickly validate the solution.”

Wireframing

Software goes through similar prototyping phases. However, unlike physical products, software products uses a concept called wireframing for rapid prototyping in early stages. Compared to more cost and labor intensive prototypes and mockups, wireframing is a way to try things out, avoid mistakes, eliminate guessing, and obtain customer approval before committing resources. Wireframing is a way to quickly communicate organization and features.

Source: Marcin Treder, Design Modo, 2016

Expand

Wireframe testing has benefits ranging from visual design choices to information hierarchy weighting to basic mistakes and omissions. Due to its low cost and speed, wireframing is a crucial step in the communication of product ideas since numerous decisions can be made without ever writing a line of code.

According to UXPin’s “The Guide to Wireframing,” wireframes communicate the following details to help different team roles agree on decisions:

Wireframes can exist in many different forms. Some people are fans of minimal pencil sketches while others like to build out quasi-wireframes with responsive elements. Browsing examples of wireframes from top UX designers illustrates how different these tools can look.

The decision behind the level of wireframe detail hinges on two factors: time to create and illustrative power. The spectrum of outputs, from sketches to working code, differs depending on the aspect being wireframed.  Ryan Singer of Basecamp clearly illustrates the tradeoffs in his post “The Fidelity Curve: How to weigh the costs and benefits of creating UI mockups.”

Consider the tradeoffs for a straightforward web UI, below:

Source: Ryan Singer, Signal v. Noise, 2016

Expand

In contrast, for a complicated web interaction, real code is much more labor intensive compared to its respective illustrative power.

Source: Ryan Singer, Signal v. Noise, 2016

Expand

The bottom line is that context is key. Wireframing, like any tool in a modern organization, must fit the team’s skills and the product being built.

Testing

Testing is the last step in the standard design thinking methodology. For digital products, “the idea is simply to observe users interacting with your web app in a controlled environment,” according to Kyle Rush, vice president of engineering at Casper.  In his article, “User testing is surprisingly effective,” Rush describes the results of user testing applied to Obama’s 2012 presidential campaign. The campaign wanted to provide a workable solution for everyone, from tech-savvy student to retired grandparent. Their user testing efforts revealed the following issues:

1. The type was too hard to for users read
2. Users did not know what format the credit card number and format should be entered in
3. Users who were not employed did not know what to enter for the employer and occupation fields

Source: Rush, 2013

After addressing these issues, the campaign reduced form field validation errors by as much as 63 percent.

Guerilla Testing

There are many different methods of user testing for software — each with pros and cons. For companies with limited budgets, guerilla testing can provide fast results.

In “The Art of Guerrilla Usability Testing,” David Peter Simon uses Designer Martin Belam’s description of guerrilla testing: “the art of pouncing on lone people in cafes and public spaces, [then] quickly filming them whilst they use a website for a couple of minutes.” Essentially, this testing method means quickly getting your product in front of your target audience and observing them using your product with very little intervention.

Simon recommends using the “Think Aloud” protocol outlined by the Nielsen Norman Group. Jakob Nielsen describes the tool as follows: “In a thinking aloud test, you ask test participants to use the system while continuously thinking out loud — that is, simply verbalizing their thoughts as they move through the user interface.” Further, he outlines the three steps you need to undertake for successful implementation:

“To run a basic thinking aloud usability study, you need to do only 3 things:
1. Recruit representative users.
2. Give them representative tasks to perform.
3. Shut up and let the users do the talking.”

The guerilla usability test and the “Think Aloud” protocol allows organizations of any type to quickly and cheaply run user tests. Product teams then need to collect the feedback and group pain points into broad categories. At first, it may seem overwhelming to translate the mass of user feedback into product improvements — but it doesn’t have to be.

Steve Krug, celebrated author of Don’t Make Me Think and Rocket Surgery Made Easy, stresses that organizations should make the smallest changes that will fix the problem. But how do you prioritize the problems on which to focus on? Beyond the obvious issues repeated by the majority of users, prioritizing fixes can be highly variable depending on the organization.

Jason Wong, Jira Software Principal PM at Atlassian, describes some possibilities for ranking a user feedback backlog:

product managers might rank their backlog based on various metrics: user growth, ROI, satisfaction, NPS, or quality, for example. We rank stories in our backlog based on our ability to impact a goal that will yield the best customer experience, which is typically something we can measure.

For example, increasing usage of a feature by x% may be a goal that we set because using this feature will deliver the highest customer value based off of our customer feedback. It’s very important to pick a measure of success that acts like your best proxy for customer experience. As the team rallies behind this goal, you need to make sure that the measure of success is easy to understand and meaningfully explains the end customer value.”

In the end, it comes down to prioritizing the user. The tasks that deliver the highest customer value may not be the most enjoyable to build, but they must be fixed before other features can be built. And after the highest priority issues are solved, it’s time to jump back into testing.

Building Using Agile

“We want to restore a balance. We embrace modeling, but not in order to file some diagram in a dusty corporate repository. We embrace documentation, but not hundreds of pages of never-maintained and rarely-used tomes. We plan, but recognize the limits of planning in a turbulent environment.”

– Jim Highsmith, History: The Agile Manifesto

Originally built for software development, Agile is a project management system now widely used by every sector and industry.

PCs took off in the early 1990s, but an “application delivery lag” quickly became apparent. In industries such as aerospace and defense, according to Peter Varhol, principal technology strategy researcher, it could take up to 20 years before a complex system was up and running. The Space Shuttle program launched in 1982, but it used information and processing technologies from the 1960s.

Agile was the result of meetings among several software developers who sought rapid ways to build software and deliver it to end users. The original Agile Manifesto had 12 defining principles for software development that emphasized a customer focus, frequent product delivery and collaboration between customers and developers, attention to detail, simplicity, and sustainability.

A fast delivery approach enabled users to get some of the business benefits of the new software sooner and allowed developers to get rapid feedback on the software’s scope and direction. Now, “continuous delivery” is a buzz phrase in the software industry and reflects agile processes and the goals of developers and DevOps who seek customer retention and market share.

Technologies based on blockchain, AI, and machine learning are complementing agile processes, and the result is much faster processing. Agile is iterative in nature, so that tasks are continuously improved. According to Lexoo, a legal services platform, tasks are prioritized based on their value, allocated to teams for completion, and processes and outcomes are improved via an ongoing feedback loop.

How to Implement Agile

Eric Garton and Andy Noble, Bain & Company partners, explain how to initiate an agile approach to projects or initiatives. The authors describe a process of iteration where operations are a “backlog” and the leadership team is “the Scrum” – a subset of agile. As projects are added, the backlog is reprioritized to maintain velocity in processes while avoiding more backlog.

Also, test-and-learn techniques within short time periods, such as one to four weeks, maintain or accelerate the speed of the process. Test-and-learn techniques work for minimum viable solutions and iterative processes where weaker solutions are quickly replaced by better ones.

The agile teams should be outside the traditional hierarchy so that they avoid slower-moving traditional processes and decision hierarchies.

Dan Woods, contributor to Forbes, describes how Google has aced agile by launching unfinished software, which it calls the “permanent beta.” Users have a lower expectation from an unfinished product, and because they are invited to engage and constructively contribute to the product by finding problems, a stronger relationship develops between the company and its customers. Gmail, for example, is still in beta. Google automates and documents feedback as much as possible and incorporates data into the user interface. Each Google product is amenable to change as users provide feedback.

Agile is Different for Each Firm

Agile is a set of principles rather than a set of strict practices. Therefore, the agile approach will be different for each firm. Steve Denning, contributor to Forbes and expert on radical management, leadership, innovation, and narrative, participated on a panel at the 2016 Drucker Forum in Vienna. Denning reported on the panel discussions on the findings of the SD Learning Consortium (SDLC). Some of the discussions centered around the agile frameworks in large organizations, including Barclays, Cerner, C.H. Robinson, Microsoft, Riot Games, Spotify, and Ericsson.

According to Denning, Ericsson is a Swedish telecommunications giant that manages 40 percent of the world’s mobile networks. It is over 140 years old and has around 100,000 employees. The company initiated Agile in 2011, and Ericsson now has over 100 small teams working in three-week cycles. The company has faster development that better meets customer needs, the customer sees value sooner, and there is less work in progress. Services are deployed one or two years earlier and revenues are also realized within the same timeline.

Spotify is a young but rapidly growing music streaming company. As of this writing, it is over eight years old with more than 2,500 staff and more than 100 million users worldwide. In 2015, a small team in Spotify used Agile to conduct series of tests to find a solution for users who wanted to find specific songs in a library of millions. The solution, called Discover Weekly, was successfully deployed a few months later, and the Discover Weekly team is one of more than 100 small teams at Spotify using Agile approaches.

While businesses large and small use different agile approaches, according to Denning, the SDLC members identified four main themes of Agile: delighting customers, descaling work enterprise-wide agility, and nurturing culture. And all four are central to successful agile approaches. Still, even with these different frameworks, there are contexts in which agile is not the best choice.

When Not to Use Agile

“This method is not beneficial when the client must work on a specified budget or schedule. You should also avoid it when clients cannot change the scope of the project once it starts.” 

— Adam Fridman, Founder, Mabbly, 2016

Agile project management is favored because, under the right conditions, it can avoid the extensive upfront planning that is typical of traditional project management processes. But it is not ideal for every situation. The table below by Bain & Company, published in the Harvard Business Review, outlines the right conditions for an agile approach and the conditions where agile is the wrong approach.

Agile is not worthwhile where processes need to be structured and consistent, such as in plant maintenance, purchasing, or accounting. Constant adaptations in these situations are likely to cause inaccuracies and errors.

The main disadvantages of agile software development, according to Adam Fridman, founder of Mabbly, also applies to other product development contexts. They include greater time commitment, more demands on stakeholders and developers, less predictability and a higher likelihood that a project will fall behind, and a lack of documentation.

There are other options for achieving responsiveness and agility without using the agile method. The KPMG 2017 CIO survey suggests buying solutions rather than building solutions and relying more on software as a service (SaaS), developing strategic partnerships, and contracting with external resources.

Agile was first developed over ten years ago, which is indicative of its usefulness, and it has undergone many changes since its inception. ADT Magazine chronicled these changes including a new agile manifesto by software engineers, how high-velocity software development according to cultural practices and philosophies has come into its own, and the new hybrid approaches such as Kanban.

Budgeting for Agile

Cognizant, a digital consultancy firm, provides a framework for budgeting for digital programs and portfolios. It emphasizes the need for budgeting tools and a financial model that can match the rapid pace of agile. The agile approach is an iterative one where adjustments are constantly made, and these persistent adjustments do not fit with traditional budgeting and accounting protocols or the waterfall model of software development with its linear, sequential design approach.

With waterfall, there is documentation and planning up front, and generally accepted accounting practices (GAAP) are applied in the capitalization of the phases of software development. Those phases where knowledge and capabilities are built are treated as investments and capitalized, becoming the company’s declared assets – for example, large R&D investments.

Operational expenses are depreciated over five years and appear on financial statements the same year. These expenses show no short-term returns or residual value and are expensed on the income statement; software testing would be considered an operational expense.

Agile capitalization is different. Agile development typically moves quickly – and with smaller amounts of operational and capitalized expenses. A sprint or a project could be completed in as few as two weeks. Also, Agile’s R&D recognizes smaller distributed chunks of capitalized and operational expenses. Better treatment of Agile’s operational and capitalized expenses can help with taxation issues, stock price, and brand reputation.

Budgeting for Agile requires dynamic budgeting and an understanding of the interdependencies of ongoing software development and the collaboration of finance and IT executives.

According to Cognizant, there must be a shift in focus from funding the project to funding the epic – high-level features that take two to three months for completion. Historically, fixed-cycle development budgeted for, say, 500 components or requirements. But these requirements might change during development and have no value at the end.

Agile ensures that every requirement has a value that is part of the epic. Included are the program, portfolio, epic leads, and budget management. The budget management group defines the operating budget and allocates resources for each epic.

As each epic is completed, the effect on the portfolio budget is reviewed to determine how much of the allocated funding was used and if it achieved its goals. This dynamic process is key to Agile budgeting because, depending on the results of one epic, the project management team may scrap subsequent epics.

Scott Ambler, senior consulting partner with Ambysoft, also emphasizes the inappropriateness of traditional budgeting or software development and advocates a “middle of the road” approach in addition to budgeting for Agile.

Ambler says that this approach calls for upfront requirements envisioning and architecture modeling that are sufficient to cover the scope of the project only. This facilitates an initial budget and schedule without excessive documentation. Ambler recommends that a small group of people who have relevant experience from similar projects in the past and who are accountable lead this stage.

This reason for minimal upfront planning is because requirements evolve over time with Agile and any early detailed documentation will likely be redundant. A ballpark estimate is sufficient. Ambler provides an overview of the Agile Model Driven Development (AMDD) approach, shown below.

The AMDD Lifecycle

Source: Ambler, Ambysoft, 2014

Expand

As the project progresses, requirements are added or adjusted in a just-in-time (JIT) manner and to obtain accurate estimates for certain tasks.

The result is that based on the actuals, the estimates are updated throughout the project for greater accuracy and future planning. The table below by Ambler compares the traditional approach, the full-on agile approach, and the hybrid or middle of the road approach.

A key point to remember is that software development is never really finished. It is an iterative process where feedback is provided, and the product is tweaked repeatedly for a better end product. Lauren Jerome, engineer and technologist, recommends establishing a development velocity plan – for example, one that measures development effort per week, which can be adjusted as priorities change.

Source: Launch Lab

Expand

The plan should also identify desired velocity based on the amount of work to be completed in each iteration and the overall budget. The scope, budget, or timeline will change as discoveries are made, but breaking the scope of work down into smaller complete pieces allows the team to avoid over-planning for features that may get cut or changed using a just-in-time approach. This type of budgeting saves time and leads to more realistic budgeting, which improves the bottom line.

Budgeting for agile adds to the conversation around budgeting for innovation, in general. For more on innovation budgets see our section on Capital.

Product-market Fit

Another component of the Lean Startup is product-market fit — the most important factor in determining a product’s success. The product failure rate is high. Whether you believe the aggressive 80-90% failure rate or the more conservative 40%, products in market face tough odds.

Why do products fail? According to research from CB Insights, the most common cause of startup (product) failure is lack of product-market fit. You may have a great team and beautiful design — none of it matters if the market doesn’t exist.

Product-market fit is easy enough to understand but hard to apply. After the development and launch of the initial product, what does product-market fit look and feel like? According to Marc Andreeson (who attributes the term to Andy Rachleff) you can feel when product-market fit is happening: usage is growing, news is spreading via word of mouth, demand is hard to keep up with, etc. But these gut checks don’t stand up well to external stakeholders.

To ameliorate this, decisions must be backed by metrics, which is easier said than done in the early stages of product development. Here are some resources on metrics that investigate and communicate product-market fit.

Resources: Testing for Product-Market Fit

If these metrics fail to demonstrate product-market fit, all energy should be spent to reach that. In the words of Mark Andreessen, cofounder of Netscape and Andreessen Horowitz:

“Do whatever is required to get to product/market fit. Including changing out people, rewriting your product, moving into a different market, telling customers no when you don’t want to, telling customers yes when you don’t want to, raising that fourth round of highly dilutive venture capital — whatever is required.”

— Mark Andreessen

While some of this language is focused towards startups, these concepts are equally vital for corporations. Once a product has reached product-market fit, a lot of the initial growing pains are gone. Stakeholders are more likely to be happy with progress and invest additional capital (if needed), and real users are getting value out of your product.

Many products don’t experience product-market fit right away. In fact, some products have to completely change markets or adopt a new business model – in other words, pivot – before they can achieve product-market fit.

Communicating the Launch

Source: Chris Maloney, 2010

Expand

Communicating the launch of your product relies on the diffusion of innovation for your target demographic. The strategies that fit product launch will not be appropriate or effective just after. This is a matter of consumer psychology to some extent.

For example, people want what others can’t have. When Apple launched the iPhone 7, the matte-black version was curiously undersupplied and, funnily enough, it was the one color that most people wanted. A cunning plan to increase demand, perhaps?

Innovators and early adopters are turned on by scarcity, whereas laggards are more turned on by social proof or by what others are talking about. Therefore, according to Chris Maloney, a multi-channel marketing strategist, when applying Maloney’s 16 percent rule and for rapid diffusion when a product has reached a 16 percent adoption rate, the message should change from one that reflects scarcity to one that is based on social proof – “a one-two punch: lead with PR, follow through with advertising.”

Caryn Marooney, Head of Technology Communications for Facebook, advises that the launch is just the beginning when it comes to diffusion; companies need a step two and step three planned out following a launch.

“Launching is like the opening move in a chess game. It doesn’t mean that much. You should only launch if you already know what your second move is going to be. This is a journey, and you need to be continuously putting points on the board. To do that, you have to know where you’re going next. ”

— Caryn Marooney

Pivot

Some of the world’s most successful businesses are the results of pivots. A change in leadership, functionality, or target market may take a product with little traction to astronomical heights. Take these famous pivots, for example illustrated by Jayson DeMers, CEO of AudienceBloom, writing for Entrepreneur:

YouTube:

“It’s hard to imagine YouTube as anything but the massively successful video streaming service it is today but its early days were nowhere near as successful. In some ways, it was always a video streaming service, but when it started, it was meant as a kind of video-based dating service, where users could upload short videos describing their ideal partner, and browse for potential matches.”

— Jayson DeMers, CEO of AudienceBloom, writing for Entrepreneur

Slack:

“Now one of the biggest names in professional chat and messaging services, Slack originated with a much different premise. Between 2009 and 2012, Tiny Speck and Stewart Butterfield made a strange but somehow popular video game called Glitch.
Rather than fighting monsters or solving puzzles, the game was focused on socialization and exploration. While the game was popular, it wasn’t profitable, so the team instead started investing resources into a new product: a chat app designed for coworkers. That worked — big-time.”

— Jayson DeMers, CEO of AudienceBloom, writing for Entrepreneur

The pivot concept covers a lot of ground. Steve Blank describes the process of pivoting as changes in any one of nine factors contributing to your business model. According to Blank:

“A Pivot is not just changing the product. A pivot can change any of nine different things in your business model. A pivot may mean you changed your customer segment, your channel, revenue model/pricing, resources, activities, costs, partners, customer acquisition – lots of other things than just the product.”

— Steve Blank

The decision to pivot is a heavy one. Founders and product leaders must weigh available data alongside the reality that some ideas just take time to grow and develop. Rather than laying out criteria for leaders to follow when deciding whether to pivot, we’ve laid out some illustrations of pivot decisions made by startups extracted from the study “Pivots in Startups: Factors Influencing Business Model Innovation in Startups,” from authors Christian Comberg, Friedemann Seith, Andrew German, and Vivek K. Velamuri.

Source: Pivots in Startups, 2014

Expand

Source: Pivots in Startups, 2014

Expand

Source: Pivots in Startups, 2014

Expand

As illustrated in the examples above, pivot decisions come from a diverse set of factors. After coding the pivots of these startups, the authors of the study discovered six key factors influencing the pivots: the role of founders, sustainability of the business model, cash and financing, market conditions, business financials, and new technology.

While the product teams should be deeply aware of these factors, in larger firms, higher-level leadership may be concerned with different metrics. To avoid this conflict, market leaders like Amazon implement company-wide data paradigms that facilitate the communication of KPIs associated with product health. For more information on building a strategy backed by data, explore our innovation strategy guide.

This clash between corporate culture and product development paradigms is a reoccurring trend. When used tactfully, design thinking and Lean Startup methodologies can help provide the structure needed for firms to develop and launch new products. However, if these methodologies are followed too closely without a culture to match, product initiatives can be put at risk.

Building Product Teams: Examples From Amazon, Google, Apple, Basecamp And Fog Creek

The final article in our series on product development deals with building product teams. Product teams may be highly subjective but there are general rules for building multifunctional teams that are both agile and creative. Explore the building blocks of successful teams alongside examples from Amazon, Google, Apple, Basecamp and Fog Creek.

“Making a product is hard but making a team that can continually make products is even harder. The product I’m most proud of is Apple and the team I built at Apple.” 

— Steve Jobs, 2014

Product teams solve problems – often problems that have never been solved before – so these teams must be highly competent. Unfortunately, there is no tried-and-tested formula that will guarantee high performing teams. Different companies use different approaches, but knowing what has worked in the past will help the CEO and business leader build successful teams and a culture to sustain them.

This article presents some of the latest research and observations on building product teams. We present examples of market leaders’ strategies: specifically, Google’s 20% policy, Fog Creek Software’s “creek weeks,” and Amazon’s “two-pizza teams.” These examples illustrate the factors that are critical to building and motivating creative teams.

What is a Product Team?

Aha!, a company that develops product roadmap software, the product team is cross-functional and has diverse perspectives from team members.

A product team’s role is wide-ranging, and its responsibilities may include marketing, forecasting, and profit and loss (P&L) responsibilities in addition to product development. Aha! describes the product team as the product’s own, personal C-suite. The team’s role is to bring that product to market, and to do so it must rely on other teams throughout the organization.

What Does the Perfect Product Team Look Like?

For many CEOs, the perfect product team is an intangible entity. Some research lists general factors that  characterize the perfect team while other research is anecdotal and case-specific. The perfect product team will be formed according to the culture and operations of its organization and, therefore, will differ in each case. In some instances, teams will form spontaneously, in others, a system will assign people to teams with strict deadlines and goals. What is the measure of a great product team? Is there a way to determine how successful a team will be? Unfortunately, there is little consensus on a method to build a great team, but there are recurring themes in the discussion such as communication, culture, and the physical environment.

An article by Alex Pentland, director of MIT’s Human Dynamics Laboratory and the MIT Media Lab Entrepreneurship Program, goes into great depth on patterns of communication, or the “sociometrics” within teams.

Pentland’s research used wireless and sensor technology to create badges worn by participants in investment teams. The badges generated over 100 data points a minute on gestures, talking and listening behaviors, and levels of empathy and extroversion. The badges were distributed to team participants in 21 organizations over seven years to measure the communication patterns of around 2,500 people.

Based on his research, Pentland claimed that communication patterns could predict the financial results of an investment team. According to Pentland, the patterns “foretell, for example, which teams will win a business plan contest, solely on the basis of data collected from team members wearing badges at a cocktail reception.”

Pentland’s insights are valuable, but while effective communication among team members is crucial, it is also obvious. So, what are the less obvious factors that are applicable in unique circumstances, because, after all, every company is unique?

Leadership Styles and Culture for Team Building

Much of team development depends on the leadership and culture within an organization. Some leaders are comfortable allowing teams to develop spontaneously. Joel Spolsky of Trello and Stack Exchange fame is a good example of this type of leader, whereas Steve Jobs preferred to build the ship before trying to steer it. Jobs’ modus operandi was to hire the best talent he could find before even beginning to create teams.

And there are secondary factors that are just as crucial if teams are to succeed, such as a safe psychological working environment. Team participants must feel confident enough to go out on a limb and take risks without fear of recrimination if they make a mistake. Finally, they must have the tools and resources that will encourage and help them to create their visions.

Let’s take a look at some exceptional product team models and the factors that make them so.

Google’s Product Teams

In 2015, Google set out to bring empirical evidence to the team debate. The company embarked on “Project Aristotle,” which identified 180 teams in its engineering and sales groups. The sample included a mix of high and low-performing teams who were then subjected to a series of double-blind interviews to determine which factors contributed the most to team success at Google.

The project leaders first had to define success. Google quantitatively defined team effectiveness by examining factors such as written lines of code, the number of bugs fixed, and customer satisfaction.

However, researchers also obtained qualitative input from executives, team leaders, and team members because quantitative measures alone are misleading. For example, more code is not always better. Google used four different types of quantitative measures for more nuanced and less subjective results.

What really mattered for team success, according to the researchers, was how the team worked together, not who was on the team. The most important factor for team members was psychological safety; team members wanted to feel that they would not be vilified for going out on a limb or for making a mistake. Also, team participants wanted to be able to depend on their peers, and they wanted structure and clarity in their purpose.

The researchers also found factors that were not particularly significant for successful team performance. According to Google’s research, teammate proximity, a consensus when making decisions, extroverted personalities, the individual performance of team members, the amount of work, seniority, team size, and tenure of teammates were not major influencing factors on team performance.

Google’s 20% Time

Abandoned in 2013, Google’s policy of “20% time” gave employees the opportunity to work on a (company-related) project of their choice for one day each week. Employees with a new idea pitched it to coworkers. If it was well received, they could create a product team with funding to explore the venture.

Gmail was one of many products supposedly born from the policy. Marissa Meyer, Yahoo CEO, dampened enthusiasm for the concept stating that projects cannot be adequately explored in the time allocated and that employees must follow their regular work in addition to any side projects. In other words, 20% time was more like 120% time. Still, other big names such as LinkedIn, Apple, and Microsoft have introduced similar policies.

Amazon’s Two-Pizza Teams

Amazon’s “two-pizza teams” have become gospel for managers and startups. This team method is so-called because the teams are small enough (six to 10 people) to be satiated with two pizzas when working hard on a project into the evening hours. Everyone loves to quote the term, but how and why does the model work?

The model originated from Bezos’ desire to create a decentralized company where teams can run with ideas independently of other operations. This model stands in stark contrast with Aha!’s definition, above, which states that product teams must rely on other teams throughout the organization.

Jason Crawford, Co-founder and CEO of Fieldbook, characterizes two-pizza teams as the ultimate embodiment of a divisional organization, wherein product teams act as independent entities within the greater organization. They have their own marketing, sales, engineering, and finance functions so that they have autonomy and accountability. “Most crucially, each product has its own profit-and-loss statement (P&L),” said Crawford.

Amazon’s two-pizza teams excel. Structure, clarity, meaning, and impact are all part of the two-pizza team design. Amazon’s special forces are deeply aware of their goals, which are cemented by highly visible metrics. And while Google’s research didn’t find a statistically significant correlation with team size and success, the size of Amazon’s team ensures everyone is recognized for their impact.

Fog Creek’s “Creek Weeks”

Joel Spolsky built up a pair of hit companies, Fog Creek Software that creates web-based project management systems, and Stack Exchange, a collection and answer platform. Spolsky has also launched Trello, an online collaboration tool. All of the company’s products were fundamentally created during employees’ free time thanks to “creek weeks.”

Spolsky has successfully spawned spontaneous teams through Fog Creek’s “creek weeks.” According to the company, a creek week is an opportunity for an employee to leave their day-to-day responsibilities for a week to focus on an idea. But only on one condition, that they convince another staff member to join them.

The unique approach of Fog Creek Software is that teams focus on validating a project by figuring out why the idea won’t work. Teams are encouraged to think how the idea might be shot down by a challenger with the right questions. For example, is the product solving a problem that many people have? Will those people like the solution and pay for it? “A typical [creek] week involves a mixture of thinking, coding, research, and a lot of talking,” says the company.

If the project still looks promising, additional resources are allocated. “As the product develops, and the idea and approach solidify, we add additional resources as needed. Glitch, for example, quickly moved from two to three people.” The team built the core product before additional resources were added in the final months before launch.

In this YouTube video, Spolsky explains how he designs his teams, typically with fewer than eight people, and how he allocates another “person” (Spolsky avoids using the title “manager”) whose full-time job is to manage communication paths among team members.

Basecamp’s Teams of Three

Jason Fried is founder of Basecamp, project manager and team communication software. According to Fried, the teams at Basecamp are limited to two or three people – one programmer and one designer, or two programmers and one designer. “Everything we take on has to be done by a team of three, max,” said Fried in an interview published on Medium. “We think three is the ideal size for most things — complexity begins to increase exponentially beyond that.”

The teams are formed spontaneously and according to the interests and preferences of the participants. There are no dedicated project managers, but designers and programmers work closely. Nor is there any formal tracking of time. According to Fried:

“We don’t measure efficiency or compare actuals vs. estimates. We have six weeks to get something done. However, if a team decides to get it done during that time, it is up to them.”

— Jason Fried

But this seemingly loose approach stimulates ideas. Fried says:

“Ideas come from all over and are offered up any time. They come from us, they come from customers… There’s always a bubbling ocean of ideas. Every once in a while, a bubble floats out of the ocean and lands on the shore. That’s when we begin to take a closer look.”

— Jason Fried

At Basecamp, these ideas become pitches, which are written down rather than discussed in real time so that readers can parse the full story. From there, Fried, the CTO, and the strategy chief debate the pitches on either Skype or Hangout and make final decisions within 30 minutes. Basecamp’s projects have a strict timeline of six weeks.

Spontaneous teams can create great products, particularly when the culture is conducive to exploration and employees feel psychologically safe. However, sometimes an organization wants more control than fate can offer.

Apple’s Cream of the Crop

When time is of the essence, a CEO needs to build a team from the best of the best. Steve Jobs of Apple was a case in point. Steve Jobs famously said that the product he was most proud of creating was not the iPod or iTunes, but his product teams.

In the book by Rama Dev Jager and Rafael Ortiz “In the Company of Giants: Candid Conversations with the Visionaries of the Digital World,” Steve Jobs’ explained in an interview that his approach to team building was to first find top-notch people.

At one point in an interview, Jobs states, “I think that I’ve consistently figured out who the really smart people were to hang around with. No major work that I have been involved with has been work that can be done by a single person or two people, or even three or four people… In order to do things well, that can’t be done by one person, you must find extraordinary people.”

Jobs addresses hardware design specifically and said, “I noticed that the dynamic range between what an average person could accomplish and what the best person could accomplish was 50 or 100 to 1. Given that, you’re well advised to go after the cream of the cream.”

Good recruiting, for Jobs, was key, and he thought this to be particularly the case for startups and smaller businesses. “When you’re in a startup, the first ten people will determine whether the company succeeds or not,” said Jobs.

For more on hiring for innovation, read “Hiring for Innovation – Courting the Candidate”

Take Aways for Building a Unique Product Team

An effective team can be created either spontaneously or through a curated process and, as we have seen, much of how teams develop depends on the culture of the organization.

For example, Steve Jobs preferred to rely on hiring the best talent that he could find. Jeff Bezos at Amazon chooses a clinical approach to building teams that limits their size, decentralizes them, and gives them autonomy with accountability. Google, LinkedIn, and others have attempted to carve out time for project leaders to develop ideas and create impetus for new products. Basecamp relies on spontaneous teams of three people or less who bandy together on mutually attractive projects, but with a strict six-week deadline for completion.

We hope this article has given you some food for thought on how to develop successful teams. The first step is to look at your current organization, its culture, and its communication patterns. Think about what models might work organically and how you can support a team-building model with great leadership and the best psychological and physical environment.