Tag Archives: product design

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.

Commercializing a Physical Product as a Solo Inventor

About once a week, a student, alumnus, or member of the general public reaches out and says something like, “I have an idea for a new physical product. I just need to find a manufacturer. Can you help me?”

First, let me be clear and succinct about a few points. First, an idea is rarely worth much unless combined with the will, effort, and tenacity to develop that idea into a product that is available to customers and that meets their needs. Second, if all you have is an idea, then you do not just need to find a manufacturer. You need to apply your will, effort, and tenacity to the process of transforming your idea into a specification of the solution that will both delight your customers and that unambiguously communicates the details of the solution to a manufacturer. That transformation is not easy. Thankfully, there are many concepts, tools, and methods that can help you achieve your goals and to avoid wasting time and money.

In this guide, I provide an overview of what you will likely need to do and I provide links to other more detailed resources relevant to your pursuit.

May I suggest that before you proceed any further, you view these videos I made describing my attempts to create a new physical product (the Belle-V Ice Cream Scoop) and to take it to market as a solo inventor. (Note that I did not remain solo for long, and had a lot of help from talented partners in the middle phases.)

Belle-V Ice Cream Scoop – Part A
Belle-V Ice Cream Scoop – Part B

OK, now you get the idea and hopefully understand that the process is not trivial, even for a seemingly simple product like an ice cream scoop. Next, let me provide more detail on the key steps:

  1. Develop a solution concept using the triple-diamond model.
  2. Create a prototype that really does the job.
  3. Design the to-be-manufactured version of the product.
  4. Make and sell 1000 (or maybe 100 if possible).
  5. Refine your go-to-market system.

I’ll also include some content related to these important financial and competitive concerns:

  • Can I actually make money from this entrepreneurial opportunity?
  • What about patents?

By the way, if teaching yourself this material is daunting to you, please consider enrolling in my on-line course Design: Creation of Artifacts in Society (via Coursera) from which some of this content is derived. Last I checked, a version of this course was available for free. (Of course, if you are a Penn student, you could also take my course OIDD 6540 Product Design.)

Develop the Solution Concept Using the Triple-Diamond Model

The Triple-Diamond Model

Diamond 1 – Jobs Analysis

Diamond 2 – Understanding User Needs

Diamond 3 – Developing a Solution Concept

Create a Prototype that Really Does the Job

Here are the videos from my Coursera Design Course on Prototyping.

Design the Product

Once you have a prototype that works very well for you, and perhaps for a few potential customers, you can actually design the product. Huh? What do I mean by design the product? I already have a working prototype. Sure, but that working prototype is not typically implemented in an economical and reliable way, and you have not fully specified the artifact in a way that a factory could produce it.

It’s possible that you can take your prototype to a factory that produces similar goods and that their employees can create the production documentation (e.g., computer models and drawings) required to actually make the components of your product. However, more typically, you need to do this specification yourself. Furthermore, the detailed specification of the product comprises your own intellectual property, and so you may wish to control it fairly closely. In that case, you will need to find someone who can create the documentation (e.g., drawings and models) that represent the production-intent version of your product.

There are lots of different types of skills that may be required for this task. I’m not able to detail them all here. A good next step may be to consult with some independent contractors via platforms such as Upwork to understand better your options.

Make and Sell 1000 (or even 100)

In all but the most time-critical competitive environments, at some point sooner rather than later you should just start making and selling your product. Ideally you would find a way to make and sell just a few — say 100 units. This will teach you so much more than doing further research and development. These first 100 units will not be very good, but hopefully they will be good enough that a few brave customers will buy them and give you feedback. The challenge is figuring out how to make just a few units that are both good enough that someone other than a family member could figure out how to use them and tolerate the inevitable warts on the product and that can be produced at reasonable cost. You shouldn’t expect to make any money on these units, but hopefully you won’t lose ridiculous sums either. In some cases you may need to find the resources to make 1000 units — when, for example, the production economics are such that it is just not possible to reasonably produce 100 pieces. Lots more to say about this, but hopefully this quick advice gets you started.

Find a Manufacturer

Here is a video on my own experiences finding a manufacturer in China. You may find it helpful.

Patents

A patent can be a useful element of a plan for developing and commercializing a product. However, it is not really a central element of that activity. Patenting an invention can wait until many of the technical and market risks have been addressed.

A patent by itself rarely has any commercial value. (An idea by itself has even less value.) To extract value from a product opportunity, an inventor must typically complete a product design, resolving the difficult trade-offs associated with addressing customer needs while minimizing production costs. Once this hard work is completed, a product design may have substantial value.

In most cases, pursuing a patent is not worth the effort except as part of a larger effort to take a product concept through to a substantial development milestone such as a working prototype. If the design is proven through prototyping and testing, a patent can be an important mechanism for increasing the value of this intellectual property.

Licensing a patent to a manufacturer as an individual inventor is very difficult. If you are serious about your product opportunity, be prepared to pursue commercialization of your product on your own or in partnership with a smaller company. Once you have demonstrated a market for the product, licensing to a larger entity becomes much more likely.

File a provisional patent application. For very little money, an individual using the guidelines in this chapter can file a provisional application. This action provides patent protection for a year, while you evaluate whether your idea is worth pursuing.

Here are a couple of videos with examples and details. (The textbook chapter I refer to in the first video is from Ulrich, Eppinger, and Yang — Product Design and Development.

Can You Make Money?

In the short run, do you have gross margin and can you acquire customers efficiently? Here are a couple of resources that may be helpful in answering these questions.

Go to Market Systems

In the long run, do you possess the alpha assets to sustain competitive advantage? Read this to learn more about alpha assets and the five flywheels.

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.

Drawing for Product Design

I made three relatively short videos to teach my undergraduate students at Penn to draw. There are many types of drawing; the focus of these videos is quick visualization tools for communicating the form of physical objects.

Video 1 – Basics

Video 2 – three simple types of drawings

Video 3 – two-point perspective