Market Assessment Framework Part 3: Prioritizing Opportunities

How do you prioritize between segments for a given market opportunity? This article discusses a framework that I have found useful to drive consensus on picking the top segments to pursue. The essence of the framework is to balance market attractiveness attributes of segments with the ability for your organization to deliver on requirements dictated them.

To make this real, recall the example from a prior article. Recall that the market opportunity described in that article was for “a product that allows non-technical users to build websites quickly. While such products have been around for a long time for building static/”brochure-ware” sites, you want to assess underserved/unaddressed opportunities. In particular, you believe online marketers might be an opportunity worth exploring further”. The table below duplicates the three segments mentioned in the prior article and discusses how the framework helps determine the top segment to pursue for this product.

The two dimensions in the framework are:

• Segment attractiveness factors: a list of factors that correlate with the potential of each segment to drive revenues. These include the size of the segment, growth rates, competitive intensity and so on. Each factor has a “relative importance” weight based on how your organization views the importance of each of these factors towards driving a decision. In the table below, we use a weight of 10 to denote a factor that is highly important to drive decisions and lower weights for factors that are less important. This is a subjective exercise. In any case, what matters are the weights in relation to each other rather than their absolute values.

• Segment requirements: a list of product requirements. Each requirement is also rated on the ability of your organization to meet it. The table below uses a score of -10 for requirements that are gaps and will take a lot of effort and time for your organization to deliver on. A score of 10 is used for requirements that are already met by your product/organization.

The first step then is to list the segment attractiveness factors and segment requirements and drive consensus on their weighting and rating. The next steps are to score each segment on:

• each market attractiveness factor. As before, use 10 if the segment scores highly on a given factor and less if it is less attractive.
• each requirement based on how important it is to a given segment. Use 10 if the requirement is “table stakes” and less if it is less important.

Finally, compute the total score for each segment by adding the segment attractiveness and segment requirements score.

As the table shows, for the example before, the “conversationists” segment is the most attractive.

Rating segments based on market attractiveness and requirements

Invention Game

A while back, the six-year old had to come up with and talk about an invention for a first-grade class project. Surely an interesting exercise, considering that she barely understood what an invention was.

As I helped her think about it, , I asked her to do the following:

1. Think of 3 things that bother her in her daily life
2. From that list, pick problems that she suspects other kids might have
3. Check if the problems in Step 2 have already been solved
4. Pick an unsolved problem in Step 3 and come up with a solution for it

For Step 1, she came up with the following problems that bother her:

Problem 1: Keeping her room clean and organized

Problem 2: Sleeping alone at night

Problem 3: Certain bodily functions that adults perform daily but she was having trouble keeping up with a routine.

In Step 2, she decided that all these problems probably applied to other kids. However, she eliminated Problem 3 because (a) it might be embarrassing to talk about it in class (b) it didn’t really bother her as much as her parents.

In Step 3, she was left with Problems 1 and 2. She decided that Problem 1 was easily solved by spending some time keeping her room tidy. So, she decided that Problem 2 was what she would pursue solving.

She came up with a design for a sleep machine. Her drawing showed a bed with a headset and a few other contraptions that I cannot possibly describe. You would apparently jump into bed, wear the headset and be lulled into sleep, or something to that effect.

P.A.S.E.R

I happened to watch the movie “Arakshan” (Hindi, 2011; translation: “reservation”) recently. As it also happens, the movie is banned in some states in India as it deals with the touchy subject of reservation (“affirmative action”) in public-funded educational institutions. While the movie itself is watchable at best, the title is actually misleading. The movie is a lot less about reservation. Rather, it underscores learning as the main outcome of an education and how the current tide of commercialized education and its diluted standards will cheapen its worth for everyone. A telling sequence in the movie shows the owner of one such commercial instution advertising to prospects that their degrees were guaranteed as long as students paid their way. The movie chronicles one educator who holds his ground against that tide.

The topic is important not just in India. PBS Frontline took this on in their “College Inc” in 2010 which ”explores the tension between the [for-profit higher education] industry –which says it’s helping an underserved student population obtain a quality education and marketable job skills — and critics who charge the for-profits with churning out worthless degrees that leave students with a mountain of debt.”

The movie brought forth some memories of IIT Delhi especially as it relates to the purpose of an education and what shortcuts in the system can do. My Mechanical Engineering class at IIT Delhi was quite adept at taking short cuts on the road to learning. To the point that one professor of a core course on power plant design had a note pasted in his office with the words “P.A.S.E.R” and this handy translation:  ”Paper Amplication of Simulated Experimental Results”. I suppose he had seen generations of Mechanical Engineers simply copying someone else’s lab reports, adding some randomization to those results and calling it their own.  Each lab session for this course was followed by a viva -an oral examination in which the student had to discuss the experiment they had conducted and his/her insights thereof. I remember one viva where the professor shouted in exasperation if the student that he was interviewing had even been to the lab and seen a steam plant at work. I suppose the paper amplications of this student had accomplished experimental results unachievable by the science of steam. 

In my time, some students made these types of choices. Others came to IIT to learn.  Cynics might point out that the PASER crowd probably did well in life. After all, someone good at PASER could arguably be said to have had a generous dose of streetsmarts as well. Probably. But, I would sleep better if I knew that the power plant in my neighborhood was designed by a non-PASER individual. Trust me, at some point, when it matters to you, you too will prefer to deal with a non-PASER type.  

 

Father Stands For Fun

The six year old is growing up fast. Below is what she wrote in her Fathers’ Day essay for school.

“Dear Dad: You are kind and helpful. You are nice and thoughtful. You are sweet and you play with me. You are smart, strong and you are a very good cook too. You make good Indian food. You make tasty Indian food, but sometimes you make it too spicy for me….Remember the day I was born. You were the first one to lift me. Remember the day you started to tease me. I liked it when you teased me. Remember the time when you did spelling with me. I was laughing and couldn’t even focus. Thank you very much for being a nice, helpful, playful, kind, sweet, thoughtful, smart and strong Dad.”

 

Close Curtain Call

The six-year old had her first ever stage performance this past weekend. She was featured in a group performing a semi-classical Indian dance. 

As the curtain opened on her group, we noticed one of the tots getting dragged with it. The tot made a few fleeting steps along with the curtain but managed to free herself just as it withdrew completely. It turned out it was my six-year old who had gotten stuck, probably because she was standing close to the curtain line. She emerged looking rather amused as the audience cheered. She continued with her performance in great spirits. She told us later on that she had fun!

Five Build versus Buy Criteria

Deciding whether to build or buy (i.e. partner for) functionality is a key question you have to answer on an on-going basis as you develop product roadmaps. This is definitely one of the grayest areas of product strategy, and this article is an attempt to highlight some of the most important considerations.

A few definitions before jumping into details. In general, there are three types of partnerships that you might want to think about:

1. Embedded components: this refers to partner functionality that is buried in your products and is not visible to end customers. Example: the comment spam filter in wordpress.com is based on such an embedded component. Google Analytics is another embedded component in wordpress.com.
2. Bundled products: this refers to partner functionality that is delivered as an add-on to your products. Example: WordPress themes are delivered this way. Many features of LinkedIn, such as its integration to twitter, Facebook and WordPress are good examples as well.
3. Go-to-market partnerships: this refers to channel partners that push your product. Example: you might use a Systems Integrator like Deloitte Consulting to drive solutions based on your offerings.

The focus of this article is to answer when you might want to partner for embedded functionality (#1 above) or bundled products (#2 above). The key questions that will help you get to an answer include:

1) What portion of the value delivered by your product is attributable to the candidate functionality?

2) Is the functionality critical to the way you compete?

3) Are there established players for this functionality with a track record of partnering?

4) Will partnering significantly impact cost of goods?

5) Will the answers to these questions change over time?

These are discussed in what follows.

Value add of candidate functionality

If the value added by the functionality being considered relative to the value of your solution is small, you might want to consider partnering for it. For example, the main value of WordPress.com is the ease with which non-technical users can create and publish web content. Given this, features such comment spam filtering are important but not central to the value of wordpress.com. Put another way, authors might choose to disable comments altogether if they think comment spams are a big headache for them. So, it does make sense to partner for this functionality.

Is the functionality critical to how you compete?

If the functionality is critical to why customers buy products in your category, you should consider building it. For example, Netflix’s ability to recommend movies based on your consumption is one of its main differentiators compared to a free video streaming site, which is probably why Netflix builds this functionality. To be sure, the dimensions of differentiation keep changing. For example, Youtube now recommends videos as well. As a result, functionality that was a differentiator at one point in a product’s lifecycle might not remain so, which should then force a re-evaluation of your build versus buy decision.

Is the functionality available from established players?

If the functionality is available from established players, it might make sense to partner with them. This is particularly true for functionality that is hard to duplicate because of proprietary technology, “hard science”, patents or other factors. For example, content search is a difficult technology problem but has established players like Google as well as Open Source solutions, so you would rather not build it if your product needs a search capability.

The converse is also true- if the functionality is not available, you have to invent it.

Impact on cost of goods

If the functionality adds significant costs to your product, you may want to consider building it in-house. If it is not possible to build it, you should consider partnering for the functionality but offer it as a separately priced add-on. For example, for some of my products, reporting/analytics is a critical value add. However, reporting is an established category with many leading players, however, with rather expensive software. So, for this functionality, I have had some basic reporting as part of the product, but have partnered with a reporting vendor to provide a separately-priced add-on to provide advanced functionality.

Impact of time

If any of these answers is expected to change over time, you should factor that into your build vs buy analysis. This might perhaps lead you to partner initially but plan to build (or acquire) the functionality over time or vice-versa.

As this article shows, multiple factors are involved in driving the build vs buy decision and the analysis may not always result in a clear-cut answer. Hopefully, the article helps you frame the issues involved.

Terms of Endearment

For about a year now, if I hear my six year old address me as “Papi” or “Popsickle”, I know that she is up to something and wants something from me.  Usually, it is nothing more than having me read a book or play a game. On occasion, she might want the forbidden candy or chocolate- forbidden by her mother, that is. Whether I give in or not is less interesting than her ability to divine what makes me squishy.

I suppose it is fair that she returns my tricks with some of her own. A while back, after she had read about Pinocchio, I happened to mention to her that she was herself a doll that had turned real with some magic.  When she was four, she found the concept unbelievable, though somewhat alarming, especially as she learned about the possibility of store-bought stuff being returned. A quick fact-check with her mother would put her at ease. Her mother would chide me for saying such things. As a six year old, when I remind her of Pinocchio-like past, she finds the idea rather amusing and wants to hear more….I think it is time to remind her of tall tales and long noses!

Market Assessment Framework: Part 2- Fixing an Existing Product

More often than I would like it to be, I have had to assess an existing product that is not performing well. Most often, I have inherited these products over the course of a product management stint.

I use the same framework as in Part 1 of this article with a few twists. This enables a fresh look at the product and category as though it was a new market opportunity. As before, I will point to an example of the framework being applied.

 Figure 1 shows the framework and is described in more detail below.

Market Assessment Framework- Existing Products

Step 1: Formulating Hypotheses

 The first step in the framework is to come up with 3-5 questions that research could answer.

 Diagnosing problems with an existing product should lead you to ask:

•  How is the product performing vs what is expected?
• Are there any fundamental changes with respect to the perception of the business problem and your product’s fit?
• What market, customer and competitor trends have emerged since the initial days of the product?
• Are there issues related to the business system (e.g. pricing, packaging, channels, positioning, field enablement)?
• What are collective opinions on what it would take to win in the current environment?

 Have a conversation with 5-10 leaders within the company on these topics and unearth opinions that leaders in the company might have about root causes and how to address them. It is also very useful at this stage to have a few conversations with industry experts, such as analysts to get an outside-in view of the market and your product’s position.

 An example of hypotheses formation

 Fifteen years ago, I had the opportunity to help a computer manufacturer. One of their product lines was a high performance computing server which was re-known for its reliability. The problem, however, was that the revenues had declined from one billion dollars to 250M over the prior five years.

 In this example, the key questions for the company to explore further were:

• How is the product performing vs what is expected? See the revenue decline stats. Management felt the product could be revived to its prior peak.
• Are there any fundamental changes with respect to the perception of the business problem and your product’s fit? Yes. While the need for highly reliable computers was real, Unix servers were increasingly the preferred solution for customers. Reliability of Unix machines was good enough and they were cheaper than the client’s product. But, there was a theory that in certain markets, the product had an edge over Unix systems.
• What market, customer and competitor trends have emerged since the initial days of the product? Unlike before, customers preferred standard hardware (like Unix systems) versus proprietary machines like the product being assessed. In addition, customers were interested in buying solutions comprising of business applications, pre-requisite software and hardware. No longer were customers interested in buying just the hardware and figuring out what applications to buy on their own.
• Are there issues related to the business system (e.g. pricing, packaging, field enablement)? The company had a Unix server division that was competing with the product being assessed. Unix products were cheaper though less reliable than the product.
• What are collective opinions on what it would take to win in the current environment? Opinion was divided between those that wanted to exit the business and focus on Unix servers versus others that wanted to understand what it might take to win.

Step 2: Research

 The second step in the framework is to research. There are three buckets of research: (a) primary research with stakeholders in the ecosystem- potential customers, competitors and industry experts and (b) secondary research of published sources. (c) data analysis

 For primary research, I usually create an interview guide that lists out potential topics to discuss with a potential customer, competitor or industry expert. Unlike a survey, an interview guide is a list of questions and topics to inform a discussion. Most important, your topics should tie back to the key questions you would like the research to answer.

 With existing products, the good news is that you will have a wealth of data on revenues, installed base customers and trends. Key things to look for include:

• Is the product growing in some segments and not others?
• Is the product growing in some verticals and applications and not others?
• Is the product growing in some regions and not others?
• What are the biggest factors that influenced recent wins and losses?
• How are direct competitors doing? Is any competitor doing well? Why?

An example of research

In the high performance computer example, we assessed the installed base data to understand performance by industry vertical. In particular, we looked for trends related to erosion of customer base within specific verticals.

 We also spoke to direct competitors, vendors of substitute products such as Unix servers, Value Added Resellers, Application Developers (e.g. ERP vendors), recent customer wins, recent losses and analysts.  

 Step 3: Synthesis

 The third step in the framework is to synthesize what you have learnt from the research step.

 Synthesis should answer:

• What explains the current position including industry trends, customer satisfaction, competitors, pricing/packaging decisions, positioning, channels and so on?
• Are there segments where the product is doing well? Why?
• What are the key success factors? Do we have them?

 An example of synthesis

 In the high performance computer example, the synthesis concluded that:

• There was a market for high performance computing solutions
• However, new customers were increasingly trending towards buying general purpose Unix hardware which offered adequate reliability at a lower price
• The product had a loyal installed base in certain verticals. But existing customers were not convinced that company would support the product in the long run, given that it had a Unix server offering
• New customers were buying applications (rather than hardware) and relied on the application vendor or their value added reseller to make the hardware recommendation. In short, the buying decision for hardware was driven by resellers and not end customers.
• Application vendors in new application categories were focusing on Unix servers.
• Like customers, existing application vendors were not convinced that the company would support the product in the long run. Most existing application vendors were rapidly porting their application to Unix servers.
• To succeed, the company had to focus and nurture its existing customer base and existing application vendor partners to ensure that they did not migrate away to Unix. The client also had to market to resellers of existing application vendors so that the product was the preferred hardware choice in a purchase cycle.

 Step 4: Strategize

The final step in the framework is to strategize, which is a collection of action items to pursue such as:

• Should we exit or stay with this product for long term?
• If yes, what changes are required to:
  •  vertical focus,
  • product positioning,
  • messaging,
  • pricing packaging,
  • direct sales force
  • go-to-market partnerships

 An example of strategy

In the high performance computer example, the recommend strategy was to stay in the market for the near term with a focus on nurturing, marketing to and growing existing application vendors and their resellers. A checkpoint in 18 months was recommended to see if further course correction was needed.

Product Leader or Product Manager?

There is a big difference between leadership and management, as I recently understood from Professor Kotter’s masterpiece (“What Leaders Really Do?”, John P. Kotter, Harvard Business Review, 1990).  I think the article provides a lot of insight into why many product organizations fail and what you should do to structure successful product teams. In particular, you have to distinguish between product leaders and product managers, as I argue below.  

Kotter’s gist is: “Management is about coping with complexity. Its practices and procedures are largely a response to the emergence of large organizations” while “Leadership is about coping with change”. The disciplines for management and leadership are different, as summarized below (adapted from the article), and successful companies combine the two, based on context, for best results.

Management: Focuses on coping with complexity	Leadership: Focuses on coping with change
Management Disciplines	Leadership Disciplines
Planning and budgeting – setting targets or goals for the future (typically for the next month or year), establishing detailed steps for achieving those targets, and then allocating resources to accomplish those plans.	Setting a direction –developing a vision of the future (often the distant future) along with strategies for producing the changes needed to achieve that vision.
Organizing and staffing–creating an organizational structure and set of jobs for accomplishing plan requirements	Aligning people- communicating the new direction to those who can create coalitions that understand the vision and are committed to its achievement.
Controlling and problem solving – monitoring results versus the plan in some detail, both formally and informally, by means of reports, meetings, and other tools	Motivating and inspiring – keeping people moving in the right direction, despite major obstacles to change, by appealing to basic but often untapped human needs, values, and emotions.

Every successful company has to balance revenues from existing customers and products with potential revenues from untapped markets, customers and products. With Kotter’s framework, one could argue that the former goal is largely a management discipline while the latter is one of leadership. Specifically, dealing with a successful product with lots of customers is a complex juggling act of priorities leading to a relatively predictable roadmap. In short, coping with complexity or “management” is what is needed for success. Assessing a new market, formulating a product vision for it and executing on the vision is indeed a lot like what Kotter considers “leadership”.

Like any other functional group in the company, product managers differ. Most excel in the management disciplines listed above, probably because many product managers are ex-engineers in many technology companies. Few product managers are great at setting direction and aligning and motivating a cross-functional team to execute. If they are around, they are best suited for charting the direction for new markets and products. Unfortunately, since few product organizations recognize the difference, the company and product strategy often ends up being driven by product managers that are great at managing existing products with a relatively stable (but possibly complex) future.  Incremental roadmaps and incremental revenues are the best possible outcomes in these organizations. A better model would be to have the product strategists that excel at the leadership disciplines lead the charge for new markets and nurture the first few product versions. Of course, once the product achieves a level of maturity and revenues, a team that excels at management can take over, if needed.

For a product team charged with tackling a new market, you do need a mix of management and leadership disciplines. Many such product groups lean on their product manager for setting the course and evangelizing it, while engineering takes care of the complex aspects of planning and executing. This model can work as long as the product manager is good at leadership disciplines. I have also seen the roles being reversed, with the engineering head providing the vision and evangelism and the product manager focusing on execution. This too can work. What does not work in new product settings is a team that has both product management and engineering trying to play the leadership role. Too many people setting the direction and aligning everyone is a recipe for chaos. Likewise if the team is full of excellent management types from product management and engineering, you often end up with products that miss the mark from a market perspective, because they are over-engineered, late to market or both.

To summarize, successful product organizations need to:

 1) Understand the difference between leadership and management as outlined above

2) Align product leaders and product managers with their appropriate sweet spots- existing products and stable markets are best handled by product managers that excel at management disciplines, while new markets and products require the leadership disciplines in their product manager.

Market Assessment Framework: Part 1- Assessing a New Market Opportunity

Two strategic tasks often come up for product managers:

• Assessing a NEW market opportunity
• Fixing an EXISTING product that is not performing well

 The purpose of this article is to provide a framework that will help you navigate these strategic projects and come up with a defensible response. Over the past decade, I have used this framework successfully both as a product manager and as a strategy consultant. To illustrate the framework, I will point to an example where this framework was applied. Part 1 of the article shows the framework applied to assessing a new product opportunity, while Part 2  applies this framework to existing products.

Figure 1 shows the framework and is described in more detail below.

Strategic Assessment Framework

 Step 1: Formulating Hypotheses

 The first step in the framework is to come up with 3-5 questions that research could answer.

 For a new market opportunity, a general statement of these questions might be (note that the questions are different if you are diagnosing problems with an existing product): 

• What is the business problem?
• What are the gaps in incumbent approaches to solve the problem?
• Are these gaps large enough to warrant a new solution?
• Why do we think we will win with a new solution?

 Have a conversation with 5-10 leaders within the company on these topics and unearth the assumptions leaders in the company might be making about this business problem and potential solutions. I try to be non-judgmental at this stage, since the goal is to understand and scope out your research than to filter out ideas. It is also a good idea to scan external data sources such as analyst reports on the industry, competitor websites, market research reports, tradeshow recordings and so on to get an outside-in view of the market.

 An example of hypotheses formation

 Fifteen years ago, I had the opportunity to help an aircraft manufacturer. This company had made ambitious growth projections for aircraft sales in China, India and Brazil because those economies were expected to boom in subsequent years, along with rapid growth in airline traffic and the need for new aircraft. The problem, however, was that the air traffic control infrastructure in these countries was simply not ready to handle the projected growth in air traffic. The situation was similar to an automobile manufacturer projecting that they could sell a lot of cars if only there were roads to drive them on. (An aside: for cars, this does not seem to be a huge problem. Indians buy a lot of cars, without thinking about roads to drive them on…). 

 In this example, the key questions for the company to explore further were: 

• What is the business problem? => How can we impact the provisioning of air traffic management services in emerging markets?
• What are the gaps in incumbent approaches to solve the problem? => The incumbent approach is to continue the existing infrastructure and do no upgrades. This approach cannot scale to address projected air traffic growth.
• Are these gaps large enough to warrant a new solution? => Yes, at least in the view of the company.
• Why do we think we will win? =>The company had a number of competencies in emerging broadband communications technologies and was reknown for its ability to assemble extremely complex systems.

 Step 2: Research

The second step in the framework is to research. There are two buckets of research: (a) primary research with stakeholders in the ecosystem- potential customers, competitors and industry experts and (b) secondary research of published sources.

For primary research, I usually create an interview guide that lists out potential topics to discuss with a potential customer, competitor or industry expert. Unlike a survey, an interview guide is a list of questions and topics to inform a discussion. Most important, your topics should tie back to the key questions you would like the research to answer.

An economics benefits assessment is also an important aspect of research to quantify potential business benefits from a new solution. A good practice is to think of before vs after metrics to analyze current solutions, their gaps and the potential economic impact of a new solution.

An example of research

For the air traffic services example, we created interview guides for many ecosystem participants including air traffic service providers (e.g. the FAA), equipment suppliers, airlines and various industry experts. Usually, 15-20 interviews with a cross-section of the ecosystem is adequate to confirm or correct hypotheses.

We also used these interviews to get an understanding of gaps in the current system and the types of inefficiencies they caused. We then built an economic model to quantify the impact of these inefficiencies.

Step 3: Synthesis

 The third step in the framework is to synthesize what you have learnt from the research step. Synthesis should answer:

• Who are the customers and economic buyers within them?
• What are the gaps in current solutions and what is their economic impact on customers?
• Is the market ready to change? If not, why not?
• What are the key success factors for an entrant? Do we have them?

An example of synthesis

In the air traffic services example, the synthesis concluded that: 

• There was a market for providing air traffic services in the emerging economies
• The customers were air traffic service providers who were government-run agencies (just like the FAA in the US).
• There were several gaps in the incumbent solution including lack of bandwidth for data communications which was causing manual tasks for airlines, highly manual processes for tracking aircraft over the oceans, IT infrastructure that was at least a decade old, and so on. Long story short, it was possible to quantify the impact of these inefficiencies on the ecosystem.
• While the market was ready for a change, the required changes would take at least a decade to pull off due to the level of co-ordination required among government agencies, standards bodies, equipment manufacturers, airlines and so on.
• Partnering throughout the ecosystem was key to success in addition to a very long term view of the market and potential revenues.
• Most importantly, because there were very few examples of private companies running these types of services, figuring out a business model that included government agencies was essential to success. Air traffic services is one of the few examples of a natural monopoly that I have seen, which is one of the reasons that private companies are not allowed serve this market in many countries. Because of the level of co-ordination required to make air traffic work, for a given country, it is best for one provider to service this market.

 Step 4: Strategize

The final step in the framework is to strategize, which is a collection of action items to pursue such as:

• Should we pursue this opportunity?
• If yes, what is the product concept?
• What is the business model? How will we make money?
• How do we go to market?

 An example of strategy

 In the air traffic services example, the strategy provided a go/no-go recommendation along with specific product (service) concepts, business models and ecosystem configuration to pursue. I have to skip details here for obvious reasons.

 Final comments

 One of the things you may have noticed is that there is no mention of market-sizing in this framework. If you do a proper assessment of gaps in incumbent solutions, their economic impact and the relative urgency of alternatives, the market sizing would simply be icing on the cake. My challenge with market size estimates, especially from professional market research companies, is that they seem to provide a bunch of numbers with little to no commentary on the assumptions, key success factors, adoption likelihood and so on. If someone insists upon market sizes, I would let this framework guide a robust set of assumptions and quantification of economic value, and use one of my other articles to size the market.

 Another thing to keep in mind is that new products often go through a number of iterations before they find their target. Youtube, for example, was apparently founded as a way to do personal ads using videos, which was thought to be better than incumbent text ads or ads with a photo. While it is not entirely clear if Youtube makes money just yet, they have indeed moved away from their initial business model. In other words, Youtube found an initial pivot around online videos but evolved it over time. This is the notion of a “pivot point” for a new product or business that others have talked about. Use the framework of this article to find and assess the pivot for a new product, but do keep in mind that things might evolve over time around the initial pivot.

Read Part 2