Tag Archives: product management

Introduction to Product Management

What is a Product?

I recently read the book “Why we sleep” by Matthew Walker. It really scared me, and I decided that better sleep should be a priority in my life. Being an analytical guy, I first wondered how good my sleep is currently, and how I could monitor the quality and quantity of my sleep. After considering and trying several approaches, I eventually adopted the Oura ring and its associated app to address this challenge. In fact I’m wearing it right now.

The Oura ring is a product. More generally, products are solutions for doing a job, delivered by a producer to multiple customers.

Probably some of you are involved with producing physical goods like the Oura ring. The term product is sometimes used narrowly to refer to physical artifacts, but I will use the term to refer not just to tangible goods, but also to software, and to services.

Here are some more examples that fall within my definition of product, all related to health and wellness, just to bring a bit of focus to the examples. Each of these products contains a solution for doing a different job. In fact, as is common in practice, I’ll even sometimes refer to products as “solutions.”

The Strava app supports fitness by measuring and analyzing running, cycling, and other activities.

SoulCycle Studios provide fun and engaging exercise while delivering a community experience.

The pharmaceutical Zocor lowers blood cholesterol levels, thus reducing the risk of heart disease.

The patient medical record system EPIC captures health information for individuals in a way that is secure, durable, and accessible across providers.

The food product Flavanaturals provides a tasty chocolate beverage that delivers flavonoids shown to improve cognitive function.

The Hamilton Medical ventilator is used by hospitals to support breathing in patients suffering from acute respiratory illness.

Many if not most products combine some tangible goods with services or software. The Oura Ring is both an app and a physical device, and physical goods like exercise equipment and medical devices typically contain a huge amount of embedded software, and likely some ancillary services.

For completeness, let’s get some pesky technicalities out of the way. 

Frankly, I could use a burnt stick and a flat rock to record a time series of subjective judgments of my sleep quality. But, that would not be a product. Products are solutions created by producers and delivered to customers.

An artifact that will be created only once, say a war memorial, is probably not best considered a product in and of itself, but the service of designing and constructing monuments could be a product, because the supplier, say an architecture firm or a sculptor, will likely do it repeatedly.

In most settings, a producer delivers a solution to a consumer in a commercial transaction. Most of the time I’ll use the words customer or user to refer to the consumer, but sometimes there are multiple stakeholders and the definition of the consumer is a bit murky.

In the simple case, consumers are individuals who both purchase products and use those products. I decide what shampoo to buy and I use it. But in other cases one party makes the purchasing decision and someone else uses the product. A hotel chain may buy shampoo for its rooms, but the hotel guest uses it. And, in this case, the customer is a business not an individual, and the customer is not identical with the user.

I like the term “doing a job” to indicate what products do, but I’m going to use several words pretty much synonymously: Job to be done, problem, gap, pain point, and even the more clinical term demand, which you probably remember from an economics course. Demand is just jobs to be done that we as consumers can’t do, or don’t want to do for ourselves.

Dozens of other categorizations of products are possible — consumables, durables, consumer packaged goods, fast moving consumer goods, and an alphabet soup of associated acronyms – CPG, FMCG, B2B, B2C. All of these are just further specification of types of solutions used in different settings to do different jobs.

Finally, there’s a special kind of product, called a platform or a two-sided market, in which the job to be done is to bring together buyers and sellers. For example, the web-based product ZocDoc matches individuals with physicians for acute medical needs. In these settings, the platform provider has two very different types of customers, the two sides of the market, the buyers (in this case patients) and the sellers (in this case physicians). 

What is Product Management

Here is the LinkedIn profile of a former student, Effie Wang. Effie served as the head of product for the dating app, Bumble, and she’s been a product manager at Amazon, ZocDoc, and GrubHub. What exactly is product management and what do Effie and those like her actually do?

Put very simply, companies deliver solutions to customers who have a job to do. Product managers stand at the interface between the customer and the resources that create and deliver products.

Product management in the broadest sense is the planning, creation, and improvement of products. These functions exist in all companies that deliver products to customers, so product management must also exist, whether or not the functions are assigned to someone with the job title Product Manager.

Some descriptions of product managers that I like include:

  • Creator or guardian of the product vision.
  • Interpreter and protector of the customer experience.
  • Guide for the technical resources to create or improve the product.
  • Prioritizer of the feature and improvement road map.

My favorite less formal description of product management, coined by my former student and co-founder of Gridium, Adam Stein is, “making sure that not even one hour of an engineer’s time is wasted.”

The role of product management varies quite a bit over the lifecycle of a product. Let me explain. I like to think of the product lifecycle as having four phases: Sense, Solve, Scale, and Sustain – The Four S’s.

Sensing is recognizing an opportunity for a new product, usually the result of some kind of disequilibrium in the market or in the technological landscape.

Solving is creating a product to respond to the opportunity, and typically launching the first version.

Scaling is the improvement of the initial product to deliver an excellent solution tailored to the bulk of the market.

Sustaining is the refinement of the product over its life, advancing both cost and product performance. While the first two phases, sense and solve, typically play out over months or a year or two, and the scaling phase another few years, the sustaining phase can last decades.

I find it useful to think of three types of product managers: innovators, builders, and tuners, which we can map onto the product life cycle. Innovators recognize and develop new opportunities. Builders start with a target and lead developers to create a great product. Tuners optimize the success of the product over its lifecycle. The scaling phase is a less clearly demarcated zone, and product managers in this phase can be thought of as builders or tuners, or a hybrid of the two.

Sensing new product opportunities, the role of innovator, may be performed by someone with the job title of product manager, or by a chief product officer, but that role could also be played by a founder of a start-up, by a business unit manager, or by an advanced development, or strategic planning group.

During the solving and early scaling phases, a dedicated product manager almost always leads the development effort. This is sometimes called “zero to one” product management, creating a new product from a clean slate. In technology-intensive hardware companies, this role may not be called product manager, but rather “heavyweight project manager” or “development team leader” or “program manager” but the role is that of the builder product manager.

In the sustaining phase of the product life cycle, dedicated product managers are typically only found in highly dynamic product environments. Dynamic environments are those for which the product changes a lot, say at least quarterly.

For instance, the fitness app Strava has dedicated product managers, but the Irwin hammer does not.

My Strava app is now version 232.0.1 updated two days ago, and Strava releases a new version (230, 231, 232, etc.) every week. The Strava app is a highly dynamic product – it changes a lot. Why is that? There are two reasons. First, it’s a software product which exhibits a high degree of modularity, so features can be updated easily and even pushed to the user on a regular basis. Second, the app operates in a highly dynamic competitive environment, and in a domain in which the enabling technologies are changing rapidly. 

The Irwin hammer on the other hand has not been updated very recently at all. It’s pretty much the same as the Stanley hammer I worked on as a product designer in 1990 (Stanley and Irwin are brands owned by the same company), and really it’s not that different from this Craftsman hammer my father gave me when I was 15. It’s not that hammers never change. They do, and when they do, the function of product management must be performed. 

For example, If there’s an emerging trend for tools to be produced in bright fluorescent colors to make them easy to find, then a project will likely be kicked off to do a redesign of the hammer. But, that decision and the planning and coordination of the effort, will likely be the result of a cross-functional discussion among the business unit manager, the marketing manager, and the engineering manager. There is not a dedicated product manager for the hammer the way there is for the Strava app.

Some people define the job of product manager as the CEO of the product. Well, that’s not quite right. Rarely does the product manager or PM have responsibility for the profit and loss of the product — that falls to the business unit manager or CEO of the business. Furthermore, while the PM may be responsible for prioritizing features, he or she rarely has direct authority over technical resources, that’s usually the responsibility of an engineering manager.

In describing the role of the PM, it’s probably better to consider specific decisions. I’ll use the RACI (“RACY”) framework to do so. Most of you have probably seen the RACI framework, but to remind you, each stakeholder in a key decision can be thought of having one of four roles:

R is for RESPONSIBLE — The responsible person actually does the work supporting a decision and delivers the outcome. More than one person can be responsible.

A is for ACCOUNTABLE — Only one person can be accountable and that person owns the results. He or she approves decisions, signs off on actions, has veto power, and can make go/no-go decisions.

C is for CONSULTED — Some stakeholders are consulted. They provide information, perspectives, resources, and support as needed.

I is for INFORMED — Finally, some stakeholders are merely informed of decisions. They are kept up to date on progress and results, but not necessarily consulted prior to decisions being made.

Now let’s consider some key decisions and which roles key stakeholders assume. I’ll show typical roles for the product manager, product marketing manager, engineering manager, business manager, UI/UX designers, and Sales manager in the context of a digital product. There are of course many other decisions and several other stakeholders, but these are the most commonly associated with product management in information-technology companies. The roles are not identical for every organization, which is one reason you may benefit from discussing these roles explicitly within your own organization, and gaining a shared understanding of who does what.

I won’t drag you through every cell of the table, but if we focus on the first column, the role of the Product Manager, we see that the decisions for which the PM is responsible and accountable are the product vision, product concept, and product roadmap, but that in this context the PM is consulted on branding, go to market strategy, pricing, growth, and partnerships.

Can Product or Product Management be a Source of Sustained Competitive Advantage?

First, I need to be clear that not all things that are important can be sources of sustained competitive advantage, resources I call alpha assets. For example, an excellent sales process is very important for enterprise software companies. That doesn’t imply that an enterprise software company can rely on its sales process as a significant source of sustained competitive advantage. It’s more that if you fail to do sales well, you are unlikely to be successful in enterprise software. We could say the same thing about operational competence for a restaurant, or accurate and timely finance and accounting processes in a bank. None of these things are likely to be sources of sustained advantage, yet they all need to be done competently to ensure success. In the same way, good products and effective product management are critically important for all companies, even if not alpha assets for all companies.

But, product can be an alpha asset in some settings. These two settings are (a) zero-to-one new products and (b) domains with very strong intellectual property barriers.

Let’s consider the zero-to-one setting. Peter Thiel famously wrote in his book Zero to One “as a good rule of thumb, proprietary technology must be at least 10 times better than its closest substitute in some important dimension to lead to a real monopolistic advantage.” I don’t fully agree with the statement, but I do agree that when there is some disequilibrium in technology or in the market, then an organization has an opportunity to move with speed and agility to take advantage of that disequilibrium and to create a product that is dramatically better than the pre-existing alternatives. At the dawn of the covid pandemic of 2020, the videoconferencing company Zoom was in the market with a product that just worked. It didn’t require registration. It didn’t require a download. It didn’t require any special gear. It just worked. Despite the fact that there were dozens of other solutions in the market at the time, including BlueJeans, Skype for Business, Google Hangouts, and WebEx, Zoom was able to seize the market and gain significant share. This was almost entirely because Zoom had a better product. Better product can be an alpha asset for a finite time period after some type of disequilibrium. This finite period of product superiority is a way of kick starting the other flywheels in an organization. But, the organization must use this precious window wisely in order to oversee the acceleration of the other flywheels for sustained advantage. Indeed, Zoom took advantage of its initial product superiority and prospered. But, predictably Microsoft was quick to follow with an enterprise product, Teams, that was at parity on many features and superior in others. Zoom remains a key player, but its product per se is no longer its primary alpha asset.

Now let’s consider intellectual property barriers. Some domains have very strong legal intellectual property barriers, which allow product itself to be an alpha asset. For example, during the same pandemic period, the companies BioNTech, Pfizer, and Moderna all created mRNA vaccines that enjoy almost impenetrable intellectual property protection. For these companies, the product itself is an alpha asset. It enhances performance and is almost impossible for a rival to acquire. 

Not all intellectual property needs to be protected by laws to be a barrier. For instance, the product of semiconductor company TSMC is a fabrication service it offers to designers of proprietary chips like NVIDIA. While TSMC has a lot of patents, its primary source of intellectual property barriers is the accumulated know-how and trade secrets embedded within its semiconductor fabrication process. Some people believe that what TSMC does is the hardest single task in the world. No one else comes close to being able to do it. In this case, the intellectual property associated with the product itself is an alpha asset.

In some settings, the product itself is only incidentally the alpha asset. In very dynamic markets – those for which some combination of enabling technologies, competitive actions, or customer behavior are changing very quickly – the organizational capability of product management can itself be an alpha asset. For example, consider the fitness app Strava. Strava does weekly product releases, which include incremental improvements and less frequently substantial product changes. Any particular version of the Strava app could likely be easily replicated by a team of developers and so the product per se is not much of an alpha asset. However, the system that Strava employs to engage its users, understand opportunities for improvement, and prioritize the changes in its product roadmap, benefits from data and experience with millions of users and a refined organizational process of product management. This organizational capability is an example of the fifth flywheel and a compelling alpha asset.

Notes

Ulrich, Eppinger, Wang. Product Design and Development. Chapter “Opportunity Identification.” 2020. McGraw-Hill.

Customer-Driven Solutions and the Waterfall Development Process

I’ve been a product designer or member of a product development team for over 50 new products and services. There’s a magic moment, which never gets old for me, when I see one of my products out in the wild being used by someone I don’t know. These days, the most common encounter is on the streets of San Francisco when I see someone commuting to work on a Xootr scooter. It’s a huge thrill to see evidence that I created something that a stranger felt offered enough value that they were willing to give me more money for for the product than it cost me to deliver it.

I did use the word “magic” to describe a moment, but I don’t want to convey the wrong impression about the overall activity of product innovation. One of the key roles in entrepreneurship or product management is leading the creation of new products, often from nothing. This is sometimes called “zero to one” product development. While luck — or exogenous factors — always play a role in determining outcomes, I believe that any dedicated team with the appropriate technical skills and with effective product leadership can reliably create a great product by using the right product development process, and that the outcome does not depend on some magic ingredient.

Why a process? The zero-to-one process is a codification of the collective expertise of thousands of developers, accumulated in government organizations, companies, consulting firms, and universities from about 1960 to the present, more than a half century of experience. A process informs the team what to do and ensures that no critical step is left out. It allows relative novices to benefit from the learning of others. As an innovator within an established enterprise, you benefit from accumulated experience in your organization codified into a process. As an entrepreneur you can reduce the risk of costly mistakes and more reliably find a compelling solution for your customers by adopting the best practices developed by the many product developers who have come before you.

in this chapter, I’m going to give you an overview of a baseline process, found in almost all organizations, called the phase-gate, stage-gate, or waterfall model of product development. This model is a useful starting point and provides an overall structure to the process of creating a new solution. In the next chapter I’m going to circle back and provide a second, simpler model of design called the triple-diamond model.

Why two models? Let me invoke an analogy to give these two models context. I love tools of all kinds. I have a fancy table saw in my shop that I really value. It takes on big jobs. It’s safe and reliable. It’s powerful and precise. It’s also big, noisy, relatively expensive, and must be connected to a dust collection system. Even so, I couldn’t do without it. That’s like a corporate phase-gate process. But, I also have a compact utility knife that I carry in my pocket pretty much all the time. I use it several times a day. It too is a cutting tool and can even be used for some of the same tasks as the table saw, but it’s unobtrusive, comfortable, and instantly deployable. That’s the triple-diamond model.

Both models are intended to be centered on the customer and to pull from customer needs. In fact, both models include engaging with users in order to identify the needs that are most relevant to product success. Furthermore, the triple-diamond model may be applied recursively dozens of times within the context of an overall phase-gate model — say at a very high level of abstraction to create an overall solution concept, or at a very fine-grained level when refining the user interface for a specific feature.

Phase-Gate or Waterfall Product Development Process

The phase-gate or waterfall process is pretty simple conceptually. First, clarify the job to be done, then understand the needs of the customer, then create a great concept for a solution, then specify details with sufficient clarity that the solution can be delivered reliably and repeatedly to customers. That simple flow is comprised of phases (or stages) — a set of development tasks — separated by gates verfiying that the tasks have been completed before moving on to the next phase.Hopefully you can see how this is a process that pulls from the customer needs to create a solution.

Phase-gate processes are also called waterfall processes because information cascades in one direction, generally from the “what” to the “how.”

Most established companies have their own phase-gate process, and they vary across different product domains. Here’s a fairly typical version. It has these steps.

Mission Statement – this phase results in the definition of the target market, an identification of a persona or representative customer in that market, and an articulation of the job to be done. It could also include a competitive analysis and goals for how the new product will be differentiated.

Product Requirements – This phase results in the creation of a product requirements document or PRD. The PRD includes a list of customer needs, and a set of target performance specifications.

Concept Development – This phase results in an articulation of the solution concept, along with documentation of the concept alternatives, the concept selection analysis, and the results of concept testing with potential customers.

System-Level Design – This phase establishes the product architecture, the major chunks of the product and the interfaces among them, and an analysis of which chunks will be custom, and which will be standard chunks provided by suppliers.

Detailed Design – This phase results in component design and specification, prototyping and testing of the chunks, and key sourcing decisions.

Quality Assurance and Testing – This phase comprises both internal and external testing to verify performance, test customer satisfaction, and to identify bugs.

Launch – This phase includes ramping up production and sales, while assuring early customer success.

For hardware products, there will be a significant parallel set of supply chain and production planning activities to ramp up the supply of the physical product. And, for service products, a pilot will often be conducted.

In any specific organization, the phases in the process are often represented as columns in a table with an implied flow of time from left to right, and the tasks, responsibilities, and key deliverables for each function within the organization are shown as rows.

The gates in the process usually involve a document (e.g., a PRD) and one or more meetings associated with a decision (a) to proceed, (b) to return to the preceding phase for additional work, or (c) to pause the effort entirely.

Evoking the waterfall metaphor, the phases are pools along a river in which substantial work occurs, including some swirling around. The gates are vertical drops between pools, marking the transition from one phase to the next. Water does not typically flow back upstream.

Phase-gate or waterfall processes have gotten a bit of a bad rap, with the critique that they do not allow for downstream learning to affect upstream decisions. However, in virtually every situation I’ve encountered, while the flow is generally from the what to the how, there is some iteration, some hiking back upstream in the process when downstream learning requires a revision in plans.

If you work in software, you know that an alternative process, Agile Development, is very common. Agile deserves its own dedicated explanation, but suffice it to say now that in an agile development process, rather than attempt to fully and completely specify the entire software product in a product requirements document and then build the system in its entirety, the team rank orders the desired features of the system and then builds and tests the features a few at a time, organized into short sprints, usually just two weeks long. Then subsequent sprints take on additional features, but only a few at a time. With an agile approach, the team is guaranteed that it always has something working, and the flexible element of the effort is the scope of features that are eventually built, but not the time allocated to complete the product. Agile processes also benefit from continual feedback on early versions of the product, which allow the development process to be responsive to new and emerging information.

Still, even for software and even in an agile environment, the creation of the first version of the product, the first embodiment of the concept, or what is sometimes called the minimum viable product or MVP, usually benefits from application of the more-or-less standard phase-gate waterfall development process, particularly the first few phases. Once a software or service product exists, its refinement and improvement over the lifecycle is highly suitable for an agile process.

Phase-gate development processes are generally logical and efficient ways to organize the effort of teams and to provide oversight and governance to the creation and improvement of products. For products pulled from customer needs, the process proceeds from a mission, to a detailed description of what the user cares about, to an articulation of the basic approach or solution concept, to a description of the details of the solution, whether that solution is software, a physical good, or a service. When thoughtfully applied, a phase-gate process ensures the organization focuses on the customer, that the landscape of possibilities is explored thoroughly, that no critical tasks are forgotten, and that different functional roles are coordinated.

Appendix – Push versus Pull Approaches to Innovation

One of my former students, Lindsay Stewart, started a company called Stringr. Lindsay had been a producer in the television news business. One of the biggest problems she faced at work was sourcing high-quality video of breaking news. So for instance, if there were a fire in the city, she would really want video footage for her story. She would have to contract with a videographer to go get that footage, edit it, and then to put it into production. That process was time-consuming, expensive, and uncertain.

Lindsay recognized the pain associated with this job and thought there must be a better way. In response, she created an app called Stringr. With Stringr, a news producer can enter a request for a particular piece of video footage via a web-based interface, and then freelance videographers can shoot the video and submit the footage using their smartphone. When the video is accepted, they’re automatically paid about 80 USD. 

Is Stringr an innovation? By my definition, unambiguously yes. I define innovation as a new match between a solution and a need. Stringr employs technology to create a marketplace connecting requests for video with the people who can create it, clearly a new match between solution and need. I call this approach to innovation the pull. Stringr was pulled from a pain point Lindsay herself experienced and has proved to be a great solution.

But, innovation can also come about in a completely different way. It can be pushed from the solution. Here’s an example.

The inventor Dean Kamen created a self-balancing wheelchair called the iBot. The big idea was that the device could rise up on two wheels allowing the user to be at eye level with people standing on their feet. The iBot was sold by Johnson & Johnson as a medical device, but once developed, Kamen thought, “Wow we have this amazing technology to balance a wheelchair on two wheels. I wonder if we could find any other application for this solution.” Several of the engineers on the development team said, “You know what? I bet you could stand on a self-balancing platform and ride it around. We could create a personal transportation device for anyone, whether or not they were disabled.” 

That thinking led to the Segway personal transporter. One of the applications that the Segway team eventually found was for Police officers, who could use the Segway to get around in environments in which space was constrained, where they wanted to be able to move slowly, and where they wanted a high degree of maneuverability. The Segway was a push – start with a solution – the two wheel self-balancing mobility technology–  and find a need that the solution can address, in this case police patrols.

The problem was that once Kamen’s company proved that police officers wanted a low-speed mobility device like the Segway, competitors took a pull approach to innovation and discovered alternative solution concepts that could address that need. In fact, once the police and security markets were proven, established competitors did enter with alternative solutions. 

A three-wheeled personal transporter is much less complex than a device that balances on two wheels, and so competitors were able to sell this product at lower prices and with greater performance than the Segway.

While an innovation can be any match between solution and need, and that match can be discovered via a pull or a push approach, three conditions must hold for the innovation to create substantial value.

First, the need must be real. That is, a significant number of customers must have a significant amount of pain, a real job to be done.

Second, the solution has to make the pain go away. It has to actually do the job.

Third, the organization must be able to deliver the solution at a cost significantly lower than the customer’s willingness to pay, and that is, the organization must have sufficient alpha assets to sustain competitive advantage.

Let’s apply these conditions to the Segway example.

First, Segway identified a real need for police officers to get around. The Segway satisfied criterion two as well, the solution concept met the need. But, Segway struggled to be able to offer the product at a price the customer was willing to pay. 

The three-wheeled configuration is a lower-cost solution that addresses that same need for police officers to get around. Ironically, Segway itself later introduced a three-wheeled version of its scooter once that configuration was shown to offer greater value. 

The big risk with the push approach to innovation is that as an innovator you fail to consider all of the possible solutions for the need that you’ve identified, and someone taking the pull approach runs around you with a better solution.

The innovator that pushes starts with an existing solution and often only considers whether or not their solution will meet the need of the target market. That is a necessary but not sufficient condition. 

With the push approach to innovation, an important discipline is to consider how a competitor would approach the identified need, but taking a pull approach. That consideration would probably have led the Segway team to conclude that a three-wheeled solution offers better performance at a lower price, suggesting the team should probably pursue the three-wheeled solution, and abandon the push approach, or else find a different job to be done in which dynamic self-balancing did offer some unique advantage.

While both push and pull approaches can be taken to innovation, In my opinion, the pull approach is much more reliable. The pull approach is at the heart of the zero-to-one product development process I teach, and forms the basis of a reliable and repeatable approach to creating value in product innovation.

Notes

Ulrich, Karl T., Steven D. Eppinger, Maria C. Yang. Product Design and Development. Chapter “Development Processes and Organizations.” Seventh Edition. 2019. McGraw-Hill.

Ulrich, Karl T. Design: Creation of Artifacts in Society. University of Pennsylvania. 2011.

Competition and Product Strategy

You may believe that you have identified a unique opportunity to create value with your new business. You’re probably mistaken about the unique part. Others have likely tried to do this job before, and some scrappy entrepreneurs just getting started elsewhere in the world probably share your hopes and dreams. Even if your insight is unique, it can’t remain a secret for long. If you are able to grow your business and achieve profitability, you will effectively be publishing the location of a gold mine to the public. Competition is a central, unavoidable characteristic of entrepreneurship. But, competition is not necessarily a bad thing, particularly at the dawn of a new market. Competitors can teach you a lot about what works and what doesn’t, spur you to innovate and move quickly, and share the burden of educating potential customers about an emerging market.

Many aspects of competition are unpredictable and so entrepreneurs should probably not spend inordinate time obsessing over rivals. Still, some attention to competition can result in smarter strategic choices in product positioning and in refining the definition of the beachhead market. Furthermore, potential investors will want to see that you have identified and analyzed the competition and have made sensible decisions about how to direct your efforts given the competitive landscape. As a way to organize this chapter and to avoid unnecessary theory, let me start with an identification of the key questions most entrepreneurs need to answer and the associated decisions they need to make. Then, I’ll illustrate several key concepts, analyses, and ways of presenting information that are most useful in addressing these questions and decisions.

What Questions are You Really Trying to Answer?

Three questions relevant over three different time horizons are usually most pressing.

First, is there really a gap in the market? This is the immediate question relevant to the decision to pursue an opportunity. Entrepreneurial opportunity is born out of disequilibrium, and for start-ups that disequilibrium is usually either (a) some technological change that has given rise to a new solution to an existing job to be done, or (b) some new job to be done that has emerged because of changes in attitudes, preferences, demographics, regulation, or other external forces. A closely related question is how big is the gap in the marketplace in terms of TAM and SAM.

Second, given that an opportunity exists, how should the specific attributes of your solution be positioned relative to the alternatives available to your potential customers? Positioning concerns both the decisions you make about the substantial features of your solution, as well as what you emphasize in your marketing efforts. This question is answered as you develop your solution, refine its characteristics, and craft a message for communicating your value proposition.

Third, how likely is your new organization to be able to sustain competitive advantage in the long term? In most cases a start-up’s most valuable assets relative to larger rivals are speed and agility. But, if you are successful, you will likely become bigger and a bit more sluggish. Existing and new companies will come for your customers. How can you thrive when that happens?

In order to answer these three questions, you’ll first form a hypothesis about the job to be done, the beachhead market, and your solution concept. If you are following the process in this handbook, this hypothesis is developed with the triple-diamond model. In any case, to consider the issues in this chapter you should have at least a preliminary decision in these three areas. In many cases, these preliminary decisions are the key elements of the description of the entrepreneurial opportunity.

With a hypothesis about the opportunity in hand, here’s a process to assess the competition, position your solution, and articulate how you will sustain competitive advantage:

  1. Identify the direct, indirect, and potential competitors and research their solutions and marketing strategy.
  2. Refine and articulate your value proposition by Iteratively refining your product positioning and by mapping your solution relative to those of direct competitors on the dimensions of product performance that most influence the value you offer to your potential customer.
  3. Develop your advantage thesis by articulating your alpha assets, the moats and barriers that you possess or hope to develop over time.

Identify Direct, Indirect, and Potential Competitors

In broad terms, competition is comprised of the organizations that deliver a solution that customers can select to do the job you have identified as the primary focus of your business. These rivals can be categorized as direct competition, indirect competition, and potential competition.

Direct competition refers to organizations that deliver essentially similar solutions to the same customer segment you are targeting and more or less addressing the same customer needs — the Coke and Pepsi of the soft drink market, UPS and FedEx for ground parcel delivery, Nike and Adidas in athletic shoes. Direct competitors are usually the most obvious and visible sources of competition.

Indirect competition refers to organizations that offer a substantially different solution to your segment for addressing the same or closely related customer needs. For example, Peet’s Coffee and Red Bull are indirect competitors for morning stimulants.

Potential competition refers to organizations that do not currently offer solutions to the focal customer segment, but who have the capability and incentive to do so in the future. For example, Amazon and Google are potential competitors in many markets where they do not currently operate, such as healthcare or education. Potential competitors are dormant, but may substantially pollute the attractiveness and sustainability of an opportunity given the possibility they may enter the market later.

Once you’ve identified the direct, indirect, and potential competitors, spend some time learning what you can about them. Devote the most time to direct competitors, but also investigate the indirect competitors; it’s possible they are more aligned with your beachhead market than you think. Your time is probably not best spent going deep on all the companies that could potentially be competitors — too much uncertainty clouds their role in your future. For the most relevant competitors, read white papers and articles; listen to podcasts; watch video interviews; try out their products; talk to their customers. These competitors, as a result of their marketing efforts, have effectively all run experiments out in full view of the public. You should take advantage of whatever information you can glean from what is working for them, what has not worked for them, and what weaknesses are revealed about them by their current efforts.

Refine and Articulate the Value Proposition

When you developed your solution concept, you probably used a concept selection matrix to compare alternatives. (See the chapter on Concept Development.) The criteria you used for comparison included the key customer needs for the beachhead market. Now pull out that list of needs again and revise and extend it until you have 6 – 10 key customer needs that will mostly determine the value that your solution can deliver to your customer.

Needs are usually expressed in the language of the customer, not as technical specifications. At this point you may wish to elaborate the metrics that most closely match each customer need. For instance, if the customer need for an electric vehicle is “has sufficient range for my daily needs” then some metrics might be “range at 50 kph average speed” and “range at 100 kph average speed” which would capture both city and highway driving.

Once you’ve compiled a list of needs, organize them in a table, along with the key performance specifications. Then, fill in the values for your solution and those of your direct — and possibly indirect — competitors. For example, Mokwheel is a relatively recent start-up company entering the electric bike market with the Mokwheel Basalt model.

Mokwheel bike solution concept. Source: Mokwheel

Here is a table showing the comparison of the Mokwheel Basalt relative to some of its competitors.

Customer NeedMetricMokwheelRad Power RadRover 6 PlusJuiced Bikes CC XNiner RIP E9 3-StarLectric XP 3.0Ride1UP 700 SeriesAventon Level.2
RangeMiles per charge on test course60453030253040
AffordabilityPrice (USD)$1,999$1,999$2,499$6,295$999$1,495$1,800
WeightKilograms35.934.325.023.528.624.528.1
Ride comfortSuspension typeFront fork suspension w/ lockout. Fat tires.Front fork suspension and rear coil-over suspension w/ lockoutFront fork suspension w/ lockout Full suspension w/ RockShox ZEB Select forkRigid frame/fork w/ fat tires for cushioningFront fork suspension w/ lockoutFront fork suspension
Payload capacityRack weight limit (Kg)8245N/AN/AN/AN/A55

The hypothesis for Mokwheel is that an affordable, rugged electric bicycle with very long range and huge cargo capacity will be well received in the beachhead market, even if the weight of the vehicle is relatively high.

Product Positioning on Key Dimensions

Competitive positioning is often boiled down to just two dimensions to allow visualization with a scatter plot. For this example, let’s assume that the two attributes of electric bikes that seem to best describe differences in products and in preferences in the market are weight and range.

Given two dimensions, we can then draw a map of the landscape of possible solutions. You could very reasonably object to this oversimplification. You’re right. In virtually any market, we oversimplify by representing the competitive landscape in two dimensions. Still, it’s done all the time, and has an obvious benefit for visualization. Recall that you have already captured the other dimensions that matter in the value proposition table from the previous section. You can experiment with which two dimensions are both important to customers and reflect meaningful differences among competitors.

Note that you can sometimes sneak in a third dimension, say price, by labeling the data markers in the scatter plot, as I’ve done with price below.

In using scatter plots for communicating product positioning, a distinction between two types of attributes is important. Weight and range are largely more-is-better or less-is-better attributes. Everyone can agree that — at least for reasonably foreseeable solutions — more range and less weight are desirable. All else equal, customers would prefer a product located in the upper left corner — low weight and high range. However, cost and technical feasibility likely make that position overly optimistic. In contrast, imagine you are designing a chocolate bar and that the two attributes of greatest importance to customers are (1) intensity of chocolate flavor and (2) crunchiness. For the chocolate bar domain, each customer likely has an ideal point — a combination of intensity of chocolate flavor and of crunchiness that they prefer. The producer can position the solution pretty much anywhere, as most positions are technically feasible at similar cost. Reinforced by these examples, we can probably all agree on some basic principles:

  • All else equal, a product should be positioned where there is demand.
  • All else equal, products should be positioned where there is little competitive intensity.
    • For more/less-is-better attributes, cost and technical feasibility constrain the position of your solution, and you likely will face trade-offs among competing attributes.

By the way, many of you have heard about or read the book Blue Ocean Strategy – that’s all the book really says. Put your product where there is demand and where there’s limited competition. Much of the field of quantitative market research is devoted to increasingly precise methods for measuring preferences and optimizing product positions in a competitive landscape. There’s nothing wrong with that logic or that approach. However, I want to warn you about two ways this approach to product positioning could lead you astray.

First, not every location in this space is feasible. Imagine, we were applying the same process, but for cameras, and our axes were image quality and size. There would be a big open area – a so-called “blue ocean” in the region of very high quality images and tiny size. Yet, the optics of photography introduce a fundamental tradeoff between size and quality, for a given imaging technology. This suggests that product strategy and product positioning in technology-intensive industries are cross-functional challenges, and that engineering breakthroughs are what allow for differentiation. For instance, the advent of computational photography, the use of image processing of several images in order to create one excellent composite image, which underlies much of the power of photography on today’s mobile devices, allows some loosening of the connection between camera size and image quality. In the electric bike market, advances in battery chemistry, motor efficiency, aerodynamics, and tire performance may allow for competitive positioning that beats the basic trade-offs reflected by existing competitors and solutions.

My second concern is probably more substantial. If you find yourself drawing two dimensional maps of your product landscape and debating the fine points of position, or if you find yourself building elaborate mathematical models to estimate market share in a crowded market for products in which a few attributes dominate consumer preference, you are probably not in a dynamic industry with abundant entrepreneurial opportunities. Rather, you are in a stagnant industry in which tuning is done by product marketing managers, and often based on mathematical models and consumer data. The goal is a few additional points of market share. If this is your situation, my advice is to find a way to make this industry less stable, to shake it up, and introduce some new dimensions of competition.

In fairness to the authors of Blue Ocean Strategy, shaking up the industry is more the essence of their message. Avoid head to head competition tuning product parameters within a highly evolved product landscape. Instead, look for a way to introduce new attributes to the competitive landscape. For example, in the chocolate bar space, consider the FlavaNaturals bar, which is made with cocoa that is super concentrated in flavonoids, which have been shown clinically to increase memory. Or consider the KIND bar, which cleverly blurs the boundary between candy and health food. It tempts the consumer with chocolatey flavor while presenting an image of wholesome goodness with the obvious use of nuts and seeds. Those are both competitors that have shaken up the more traditional dimensions of competition in the candy bar market.

Develop an Advantage Thesis

I’ve written a lot about competitive advantage elsewhere. (See Alpha assets and the Five Flywheels.) But, in sum, advantage always arises from controlling or possessing some resource that significantly enhances your performance in doing a job and that your rivals can’t easily get. I call those resources your alpha assets.

A unique solution is usually the start-up’s initial alpha asset. In a few rare instances, the solution will remain hard to imitate for a long time. For instance, in the pharmaceutical industry a new molecular entity can be patented, and what is patented is what eventually receives government approval. Thus, rivals can not offer the approved compound without infringing the patent. Given the typical time requirements for commercialization, such patent protection may offer 10 or even 15 years of exclusivity. But, outside of the biopharmaceutical industry, patents rarely provide strong barriers to imitation for very long (Ulrich, Eppinger, and Yang 2019). Your unique solution combined with your speed and agility probably give you a few years of advantage, at which point you had best have developed other sources of advantage. The most likely are brand and the scale economies enabled by a large established customer base.

Why Can’t Google Do this?

One of the most common questions that entrepreneurs face from investors is “Why can’t Google (or Apple, Meta, Amazon, et al.) do this?” This question reflects the concern that Google, or any other large and powerful company, could enter your market and offer a similar or better solution than yours, using their vast resources, capabilities, and customer base. The “Google question” is common enough to consider specifically. The answer varies depending on your industry, market, and product category. For example, consider how the answer may differ for two start-ups, one pursuing on-line dating and one pursuing cloud-based video services. Although these examples are specific to the competitive threat by Google, they are illustrative of how an entrepreneur might think about competitive threats from any large, powerful incumbent.

Google could enter the online dating market and offer a similar or better solution than a start-up, but it is unlikely that they will do so for several reasons. First, online dating is not aligned with Google’s mission, which is to organize the world’s information and make it universally accessible and useful. Second, the online dating market is fraught with privacy concerns. Google may face legal and ethical issues if it enters the online dating market and uses customer data for matching purposes. Third, online dating is a highly competitive and dynamic industry. Google may not exhibit sufficient agility to keep up with changing customer preferences and needs, as well as the emerging technologies and features in the online dating space. Putting these reasons together, one could argue that Google is not a serious potential competitor in the online dating market. In sum, Google could do it, but Google won’t do it.

Google could also enter the market for cloud-based video services and offer a similar or better solution than the start-up. They might credibly do so for several reasons. First, cloud services is their core business and competency. Google already offers a range of cloud services products such as Google Cloud Platform, Google Workspace, Google Cloud Storage, etc. It has the incentive and interest to enter a niche or specialized segment of the market in order to stimulate demand for Google’s core services. Second, cloud services is a technologically complex industry. Google has the resources and capabilities to enter the cloud services market and offer a high-quality and reliable solution that meets the needs and expectations of customers. Third, cloud services is large and growing industry. Google not only could do it, but Google likely will do it, and has the opportunity and potential to enter the cloud services market and capture a significant share of customers and revenue. If you are in the directly path of a company like Google in its core business, then you will likely need to make an argument about the importance of speed and agility, and some important alpha asset — such as network effects — that can be developed in the two or three years it will take Google to recognize and respond to the opportunity. You may of course also argue that Google would more likely acquire your start-up than build its business from scratch. Such arguments are weak, in my opinion, unless you can make a credible argument for why your start-up will have significant alpha assets within a few years, and in that case, whether or not Google would acquire the company, you have built something of substantial value.

Wrap-Up and Common Pitfalls

Your business plan or “pitch deck,” whether for investors or just for your own planning, should have a section on competition. Everyone expects that, and for good reason. You’ll usually have a table showing how your solution stacks up against the rival solutions on a handful of key customer needs. You’ll likely show your product position relative to direct competitors on a two-dimensional plot. You’ll devote some space to an articulation of your planned sources of long-term competitive advantage.

Do those things and at the same time avoid these rookie mistakes:

  • Do not claim that you have no competitors or that you are better than all of them. Every job to be done has been around in some form for a very long time in society. Your potential customers were getting that job done somehow before you had your bright idea. The pre-existing solutions are competitors.
  • Do not be dismissive of competitors. If there is an existing company doing the job you are setting out to do, then that company is more accomplished than you are at the time of your analysis. Show some respect and learn from that company’s experience.
  • Do not argue that you are the first mover, and that this is a source of competitive advantage. There are rarely first-mover advantages, except sometimes when the market exhibits very, very strong network effects. Consider that Google was not even one of the first ten companies to enter the internet search business.
  • Do not cite patents or “patent protection” as a significant source of competitive advantage. Unless you are a bio-pharmaceutical company, patents are at best a low picket fence around your solution. They are not typically a significant barrier to entry.

Notes

Karl T. Ulrich, Steven D. Eppinger, and Maria C. Yang. 2019. Product Design and Development. Chapter “Patents and Intellectual Property.” McGraw-Hill. New York.

Karl T. Ulrich. Alpha Assets and the Five Flywheels. Working Paper. The Wharton School. 2018.

Kim, W. C., and R. A. Mauborgne. 2005. Blue Ocean Strategy: How to Create Uncontested Market Space and Make the Competition Irrelevant. Boston: Harvard Business School Press.