0

Product Management – Book of reference

Share

Solve Real Problems with Design Thinking – Book Overview

  • analytics,
  • business modeling,
  • coordination, and
  • design thinking

 into what we call as Digital Product Management Thinking, or DPMT.

Why?

  1. Because the distribution and the use of digital products produces rich data.
  2. Because product features and customer value
  3. can be constantly modified using lean and agile processes.
  4. Because user experience is far more critical today than in days past.
  5. And because these digital products are increasingly a whole, or a very large part, of business ecosystems.

The second reason our course is different is that we treat product management not just as a job description, but as a way of thinking that is applicable beyond the individual product manager.

We view Product Management Thinking, or PMT, as a shared, problem-solving approach that can help entire product teams become more effective.

You will also be able to access a curated selection of cutting-edge blogs on the unique challenges of going digital. In order to turn know-how into PMT skills, we will immerse you in Course-Long Problem Context, or CLPC, exercises. These exercises include feedback and discussion mechanisms that will draw upon the wisdom of motivated peers–literally thousands of fellow PMT learners with diverse backgrounds from all over the world.

In short, this course will provide you with a systematic, interactive, and practice-based overview of product management, while keeping your career aspirations in mind.

We will also encourage you to consider product management not just as a set of personal skills, but as a way of thinking that you can get your teams to adopt.

Having everyone around you think like a product manager could be the key to your long-term success.

Product managers are treated like rock stars because they make a difference between the success

or the failure of a startup team. What makes some individuals, such as Sundar Pichai, the current CEO of Google, who started out as a PM, successful?

What type of personal skills and business perspectives are necessary to be successful and to grow in such a role? The answer is, of course, complex, because product management processes require problem solving and decision making in many areas

  • market research,
  • software engineering, and

supply chains, for instance.

Requirements in one of these areas may have a conflict with requirements in another area.

The PM need not be an expert in any one of these areas.He or she is the coordinator, or the glue,

that pulls the team together to get them to buy into the underlying tradeoffs. The crux of coordination and resolving conflict across areas lies in developing a shared understanding of the business model.

Business models and their implementation for the PM decisions are not easy to discern.Part of the challenge is to collect the relevant pieces of information from different sources.

Moreover, in the digital economy, these models and underlying technologies change rapidly. Strong grounding in the basic principles of businesses necessary to deal with such changes and ambiguity.

We will serve a key concept in

business strategy,

such as

  • skill,
  • scope, and
  • speed, and then

introduce the

  • Business Model Canvas, or the BMC, as a framework to assess and implement such strategies.

The BMC will allow a PM to take a systems view of the trade-offs – for example, the decision to invest in supply chain instead of marketing -and to explain to various stakeholders how such an investment decision may affect the business outcome. When clear guidance is not available, a PM may have to use the Canvas to reverse engineer the business model using the best available information.

Success of the product begins with having a very clear vision. This vision is embodied in the BMC analysis. An ability to understand, and better yet, to shape the BMCis central to the cross-functional coordination that the PM is required to carry out.

Learning Steps

A product manager (PM) is responsible for the product’s lifecycle — from its conception, development and launch to its sunset. This responsibility is either formal — via management appointment or job description, or implemented informally — through personal connection and capabilities within the team or with a network of colleagues such as software developers, user interface designers or supply chain experts.  Given the centrality of such connections over the lifecycle of digital products, all the members of this network are either PMs, PM partners, or potential PMs in making who share a way of thinking about the success of their product. This course is about Digital Product Management Thinking (DPMT) – which we define as integration of

  • Analytical,
  • Business model,
  • Coordination and
  • Design thinking (i.e. the ABCD of DPMT).

We will systematically explore DPMT in term of the decisions that PMs must make in the digital product management process, and skills that the PM must develop in order for the team to succeed. We introduce a few core concepts and exercises that will help reinforce your understanding of DPMT according to the following steps:

i.          Introduce a few key “starter” conversations or perspectives on product management such as the role of the product management and career trajectory, along with the skills needed by PMs, such as understanding business models, and implementing design thinking.

ii.         Understand that mastering process details (e.g., lean and agile software development practices) is a central coordination skill in product management. Systems thinking (i.e., how various parts work together) is essential for such coordination, for balancing multiple and competing perspectives that often arise in such processes.

iii.        Illustrate that a key characteristic of emergent digital products is the need to leverage data and analytics capabilities, both by the development team and the end users.

Key Concepts

  1. What’s In It For Me (WIIFM): Few professions today are as rewarding or sought after as product manager (PM). As a PM, you get to work with smart people to define and drive products and services that will hopefully change the world. PMs are some of the highest paid individuals, especially in technology hubs such as the Silicon Valley (Coren, 2016). In the long term, product management exposes you to all facets of business and may be the perfect training ground for senior executive roles or for launching your own startup. With PMs compared to “rock stars” (with salaries for some nearly as high!) — what’s not to like?

Optional Open Source Readings:

For an inside look at the digital industry where PMs are treated as rock stars (article by Ray Tsuchiyama) 

Some evidence that product managers get the top salary offers (article by Michael Coren)

  • The Role of the PM: PMs often are responsible for the product’s outcome, but unfortunately, have zero to little direct authority over the resources required to achieve that outcome. Some PMs may focus more on the initiation of new products while others may be tasked with more mature lifecycle elements such as enhancing or sustaining a product or managing ongoing market perception. Regardless of the type of product, good PMs are
  • strategists,
  • cheerleaders, and
  • champions for their products.

Therefore, the key skill for a good PM is having a solid grounding in the process of product management and knowing how to use that process to drive results. In subsequent parts of this course, we will explore the different facets of the product management process and a PM’s role within that process.

Optional Open Source Reading:

A description of PM role as an intersection between Business, Technology and User Experience (article by Martin Ericksson)

  • The PM as “Product CEO” (or not): An ongoing discussion in the product management community, following Ben Horowitz and David Weiden’s essay, “Good Product Manager, Bad Product Manager,” is about whether PMs should consider themselves as “Product CEOs”. Some have argued that the high level of strategic decisions of the PM, such as whether to pivot or change the direction of a product in development should involve all senior managers —  folks well above the PM’s paygrade and status — or not. One advantage of a senior executive, such as a CEO, making such a decision is that it is visible to the entire team. While the PM should be an important voice in such pivots, s/he should absolutely excel at the lower level operational details (e.g., which features to develop and when) and the coordination of work, and make those decisions within the PM team. Anecdotal field studies conducted by over 25 student teams (from PM courses taught by one of the instructors) in leading digital firms in Boston and Silicon Valley in 2016–17 indicate that One Size Does Not Fit All (OSDNFA) in terms of the PM’s role and responsibilities in terms of the level of authority, responsibilities and the processes to follow. We will discuss such variations as we develop this course.

Optional Open Source Readings:

Ben Horowitz and David Weiden’s article about the PM leverage and the consequence of Good and Bad PMs  

  • Moving Up The Ladder: Large organizations often have well-defined and stratified product management roles, ranging from entry-level Associate Product Manager and Project Manager to Director/VP of Product Management and Chief Product Officer (CPO).  Small companies may have just a few PMs and little hierarchy. Being a PM is also great training for other senior organizational roles in general management and business development.

Optional Open Source Reading:

Blog by Mike Fishbein, which advocates that having experience project managing successful products, along with grit, persistence, and luck are the key elements of long-term success.

Coordination Skills and the Ability to Leverage Processes

How important is it for a PM to be technically proficient? Many would argue that while having a technical background has its advantages, many great PMs have minimal technical training and experience in IT, programming, engineering, software development, and the like. In fact, many come from liberal arts backgrounds. In reality, “soft” skills such as listening well, planning, empathy, writing well, and persuasion (both oral and writing) are just as important as knowing exactly how a technology works. PMs or potential PMs can reduce their learning curve in various ways, such as reading popular journals in the targeted technical field, keeping a list of terminology (e.g., jargon) and learning it, and attending meet-ups to ask questions and to network (Vogt, 2017). There are exceptions to this technical background rule: some PM roles require high-level technical knowledge for technical products, such as predictive analytics techniques and cognitive computing where hands-on technical knowhow, such as statistical inference, is absolutely essential for all members of the PM team.

Given the great diversity in PM roles and profiles, what success factors can be generalized?  We make the case that successful digital PMs do share common traits. They:

  1. Understand (and know how to manipulate) the business and organizational context within which they operate.
  2. Are proficient at the process of digital product management – from ideation to go-to-market and beyond.
  3. Have a versatile repertoire of ‘soft skills’ such as empathetic listening and persuasive communication, and are aggressively committed to continuous learning.

Figure PI-1 shows core PM tasks including gathering user stories and leveraging design-thinking skills to specify customer needs, tracking profit and loss, and aligning product decisions with business models (in black circle of Fig. PI-1). These tasks are carried out in conjunction with cross-functional processes such as marketing and supply chain coordination. PM tasks often involve solving conflicts that arise due to differing objectives of the multiple stakeholders (e.g., a user interface designer trying to simplify a product versus a marketer who wants to add use features to increase product appeal).

Figure PI-1 gives a visual representation of how product management is the “glue” that brings together many of the necessary components to have a successful product. In specific, product management sits at the intersection of some core activities requirements and the integration of other cross-functional activities. The core activities are: business model assessment, P&L management, and customer needs assessment. Cross functional activities are: analytics, experimentation, marketing, project management, software engineering, supply chain management, and user interface (UI).

Figure PI-1: Integration across multiple functions and stakeholders

Great PMs develop process-coordination skills to set up and schedule processes and align them with practices (e.g., lean and agile software development practices, A/B testing), in order to make cross-functional decisions.  Systems thinking — how various parts work together to build synergy towards common goals that align with a team’s business model — is essential to manage multiple competing perspectives common to such processes. We will provide you opportunities to learn about such practices, explore tradeoffs and to engage in systems thinking through course long problem solving exercises.

CLPC Exercise

The “Course-Long-Problem-Context” (CLPC) serves as a learning laboratory throughout the course. Your CLPC exercise will also serve as the basis for online discussion with fellow students. Steps for this CLPC exercise across different parts of this course are shown in Figure PI-2.

We will go through a simulation of working as a product manager to develop a product in 6 organized steps. The steps are visioning, hypotheses generation, minimum viable product design, measuring market response, profit and loss assessment, and roadmapping.

Figure PI-2: Six-Part CLPC Exercise

For example, the goal the CLPC exercise in Part I is to reverse engineer the strategy of an existing product as a benchmark. Output from each exercise part serves as input for your follow on work. The end goal of the exercise at the conclusion of Part VI is to construct a roadmap for a sequence of useful and viable product concepts. Instructions for Part I CLPC exercise are available in a follow on tab.

No two situations are exactly the same. One size does not fit all. And that’s the reason a PM needs to be somewhat cautious about overreacting to the buzzword or the fad of the day.

Yes, lean, agile, business canvases – these are great concepts. But blindly applying them into every context is something that a product manager needs to be careful about. One thing I wish I had realized earlier in my career is that product management is as much a social activity as it is a cognitive activity.

Because a product manager not only needs to figure out what the right answer is or what actions to take, a product manager needs to convince others to come along for the ride.

Doing this right, requires you to build out the right network of people. And these are people that are both going to help you get to the right answer, and these are the people whose support you’re going to need in order to execute upon that right answer.

Unfortunately, the act of building this social network out doesn’t come naturally to many product managers.Many of us are former engineers by training, or perhaps, a little more introverted than others.

And the idea of manipulating a network or the idea of actually creating a network of people who will help you is just something that feels a little unnatural to some of us.

But honestly, the difference between an average product manager and a great product manager is not necessarily what they know but it is who they know.

Learning Steps

While PMs are not responsible for authoring their company’s business strategy, it is critical that they understand and analyze the company’s business model and are comfortable discussing it and seeking clarification on the strategy from senior management. A PM is responsible for designing a product strategy for developing a product or product family. However, the product strategy must generally be developed in the context of the company’s or business unit’s strategy. We cover these issues in the following steps:

i.          Introduce concepts from the broad area of firm-level strategy that the PM will need to understand.

ii.         CLPC (Visioning): Reverse Engineer the Business Model of your platform partner to gain insights for the opportunities that may be explored.

iii.        Use a Business Model Canvas to view, via a systems lens, the firm’s business strategy and identify development tradeoffs and organizational challenges faced by a PM.

Key Concepts

Generally, product strategy is aligned with business strategy. For example, if a company competes on offering the lowest price product and fast delivery, then a product strategy for a high-end product that is customized over time to fit a niche customer might rightly be considered non-aligned, and therefore a questionable strategy. Note that it is possible that the product strategy may be a conscious attempt by the company to experiment with a new business model and the lack of alignment could be “by design,” but it is good practice to always question and clarify such atypical plans. To facilitate a conversation on strategy, the PM must be familiar with commonly used strategy frameworks and terminology often used by senior executives. Here we define six strategy frameworks:

  1. Michael Porter’s Frameworks: Strategy is often described in terms of whether competition is based either on cost or “focused differentiation” (i.e., wherein a small group of customers is targeted based on differentiated product features) (Porter, 1996). Popularized by economist Michael Porter of Harvard Business School, such categorization of strategies are often referred to as “generic strategies” and are often developed based on industry analysis (i.e., by looking at all the key firms in an industry such as the automotive sector). This process uses Porter’s “Five Forces” model and his SWOT (Strength, Weakness, Opportunity, and Threat) analysis.
  2.  The five forces are threat of new entrants, threat of substitutes, bargaining power of customers, bargaining power of suppliers, and industry rivalry.

Optional Open Source Readings

Basics of 5 forces model (by Mind Tools Editorial Team)

In-depth look at “focus” (or niche) strategy (by Eric Wagner)

  • Scale and Scope: A core building block in strategic planning is the distinction between economies of “scale” and “scope” (Chandler, 1994). Raising the scale of production reduces unit cost, and thereby creates advantage for a firm with a larger sales volume than its rivals. Scope refers to a firm’s efficiencies formed by increasing its product variety or scope.  Thus, a strategy built around scale generally requires a different supporting product strategy than a business strategy built on scope.

Optional Open Source Reading:

Further definition of scale and scope (from the Economist)

  • Blue Ocean Strategy: Some firms have a better chance of success by creating a new market or a product category rather than competing in established markets. The concept of “red oceans” (competitive markets) versus “blue oceans” (new markets and categories), introduced by Kim and Mauborgne (2005), scholars from one of the world’s top-ranked business schools (INSEAD), is now a standard framework of corporate strategists.

Optional Open Source Reading:

Further explication about blue vs red oceans (by Rachel Smith)

  • Core Competencies: A traditional but still relevant way of formulating strategy is to understand and build on the company’s unique resources or “core competencies,” a term introduced by management scholars C.K. Prahalad and Gary Hamel (1990). For example, Intel’s core competencies include designing, producing, marketing and distributing micro-processors.
  • Agility / Adaptation Strategies: An alternative view of strategy focuses on learning and adapting to change. In this worldview, strategies such as competing on cost or focus differentiation are temporary; even core competencies can become irrelevant. The key for surviving and thriving over time in certain markets is agility, or the speed at which decisions are made and implemented. For a discussion of speed and agility in digital strategies, see Venkatraman (2017).

Optional Open Source Reading:

An article from long range planning that introduces the key concepts of agility and how companies leverage agility (by Yves L. Doz and Mikko Kosonen)

  • Core and Edge: Companies use the terms “core” and “edge” to delineate different parts of the business and their importance. As a PM, it is important that you know whether you’ve been tasked with defending the core or extending the edge, or both. For a discussion of core and edge in digital strategies, see Venkatraman (2017).

Optional Open Source Reading:

Consultant’s tool for explaining core and edge (by Varun Nagaraj and Doug Billings)

  • Business Model Canvas:  We argue for a systems-thinking approach (i.e., look at the effect of a firm’s individual actions synergistically) to examine a multidimensional mapping of business strategy and allied product strategy. A popular approach to concisely describe product strategy is the “business model canvas,” (see Fig. PI-3) popularized by Osterwalder and Pigneur (2010). The BMC categorizes key decisions into nine boxes or elements. While initially developed to facilitate business model discussions, the approach has been incorporated by product development experts like Steve Blank who recommend using the BMC approach to provide the product strategy input to lean development projects (Blank, 2014).  We further address lean development in Parts II and III.

Optional Open Source Readings:

Ted Greenwald’s article in Forbes about the use of Business Model Canvas as a tool to design Business Models

Alexander Cowen suggests a rapid Business Model Canvas exercise yields business plans with focus, flexibility and transparency

Here we have a blank Business Model Canvas with the critical areas that a product manager must monitor and coordinate as described in the video “Business Model Canvas Overview.”

Figure PI-3: Business Model Canvas template (courtesy Strategyzer)

Please watch Lee Garf’s testimony on why business context matters in making strategic PM decisions.

Sample Solution

CLPC Example: Nike+

Nike started the original fitness meets technology trend with it’s Nike Band. However, over time, it moved away from producing hardware that was not shoe related (making bands) to provide an “ecosystem” where data that is collected could be displayed on a platform called Nike +. In addition, Nike makes its own brand of shoes that have sensors in them to transfer data to the Nike + environment through specially geared APIs.

Data Sources (30 minutes) Target (Nike+): “Nike+ is an ecosystem of digital products and experiences designed to measure, motivate and empower you to improve. by tracking your progress and allowing you to share your sports data, Nike+ offers you ways to measure up, compare, compete and excel.”Historical Context & Timeline: Mark McClusky described the history of the use of personal metrics as part of Nike+ products in a Wired Magazine article.Initial Search Key words: Nike plus sensor wiki; time line; disruption; partners. Key Component Technology: Piezoelectric sensor, receiver.Major Disruption: This article is an exclusive on the news of Nike firing the majority of its FuelBand TeamPartners:Article on the Global Expansion run by Nike+

Figure PI-4: Data Sources for Sample Example

BMC Here is a filled-out Business Model Canvas with the critical areas that a product manager must monitor and coordinate as described in the video “Visioning”

Figure PI-5: BMC for Sample Example (BMC Framework Based on CC License from Strategyzer.com).

Assumptions & Organization of Data External motivation (for athletically inclined folks) is a critical factor in the value proposition.Channels: technology retailers and social media reviews are critical.Customer Training was not explicitly mentioned, split it from marketing and added to key activity. (assumptions need to be verified)

Figure PI-6: Assumptions for the Sample Example

Inferences Overall: From Hardware (2012) > To Leveraging Platforms (2015 onward).Existing Apps in Nike+ Ecosystem: Nike + Basketball (developed by Nike). From Partners: Garmin for GPS, TomTom for GPS, Wahoo for Heart Rate, Netpulse for health clubs. Gaps: Nothing available for niche sports like Pole Vault, Rowing etc. (Even though Nike has shoes for use cases.)

Figure PI-7: Inferences – Gap and Vision for the Sample Product Space

BMC: Additional Analysis

A key point is that BMC allows for multiple pathways for businesses to set up, implement and evolve their strategy. In some settings, firms may be using digital technologies by leveraging scale or scope, to create a blue ocean (new markets or new product categories). Setting up scale and scope, or other attributes such as agility, is not easy because they create tradeoffs and decisions that must be considered systematically. The BMC maps the business model into nine key elements (or boxes) as shown in Figure PI-3: partners, activities, value proposition, customer relations, customer segments, key resources, channels, cost structure and revenue streams. It is worth reviewing Figure PI-1 and think about who “owns” these elements. Different stakeholders in a PM team often represent different aspects of these nine elements, and it is the PM’s job to address the synergies and tensions between them by acting as the coordinator. Either reinforcing or opposing interactions or effects can be associated with individual decisions across these key elements. Table PI-T1 offers a step-by-step procedure to fill out the nine BMC boxes, assess their potential interactions and their impact on the business model.

(Caveat – these 7 sub-steps can be be a part of STEP III of the CLPC inference work outlined earlier)
Step 1Collect data from primary and secondary sources pertinent to the BMC.
Step 2Assign relevant information to the nine boxes in the BMC. A PM may have to make assumptions to assign some of this information.
Step 3Think about interactions of variables across boxes based on the six strategy frameworks described earlier. (e.g., Does an outcome parameter (such as revenue) scale up when another parameter (e.g., number of partners) increases?)
Step 4Assess alternative strategies (e.g., scale vs. scope). It may be possible to hypothesize a causal loop diagram (see Figure 2.2) to capture underlying interaction effects.
Step 5Will adding or relaxing some interactions create a potentially novel business model Might such a choice create additional key activities in the BMC?
Step 6Reflect: Should additional data be gathered to flesh out assumptions?
Step 7Reflect: Could this BMC analysis help to clarify detailed operating decisions, and resolve conflicting interests within the PM team by addressing tradeoffs?

To understand interactions and their causal effects (steps 3 and 5), imagine that a firm such as Microsoft decides to create a platform such as Xbox so that multiple independent software vendors (ISVs) or partners such as Electronic Arts (EA) (makers of Madden NFL software games) may produce and sell products for the Xbox. We illustrate allied interactions in a causal loop diagram (Sterman, 2000) shown in Figure PI-9 with two revenue streams: direct platform fees, paid by end customers, and licensing fees paid by the ISV partners. The relationships between the BMC elements that drive the evolution of these revenue streams is shown in the outer and inner loops of Figure PI-9. They correspond to economies of scale and scope, respectively.

The relationships between the BMC elements that drive the evolution of these revenue streams is shown in the outer and inner loops of Figure PI-9. They correspond to economies of scale and scope, respectively. The outer loop shows a scale effect: as the number of ISV partners increases, the value of the platform (in this example, the number of available games on Xbox) increases. This, in turn, increases the number of customers and allied direct revenue. Increased direct revenue increases the motivation for increased ISV partners. On the other hand, the inner loop indicates a scope effect that balances the ISV growth. As the number of ISV partners goes up, the cost of supporting the heterogeneous needs of various ISVs goes up, and the channel revenue goes up. Taken together, the channel margin goes down. As the channel margin goes down, the number of ISV partners is reduced. For example, as the number of custom APIs for the Xbox goes up, the cost of supporting ISVs goes up, and if the licensing fee from the ISVs is not growing, the profit margin goes down and the platform looks for a more focused development strategy by reducing the number of ISVs.

 Evolution of scale and scope effects with multiple independent software vendors (ISVs).

The outer loop shows a scale effect: as the number of partners increases, the value of the platform (in this example, the number of available games on Xbox) increases. This, in turn, increases the number of customers and allied direct revenue. These dynamics provide additional impetus to increase the number of ISV partners. On the other hand, the inner loop indicates a scope effect that goes in the opposite direction: as the number of ISVs (scale) goes up, the perceived value of using a platform (e.g., Xbox gaming device) goes up, and thus the number of customers increases. This in turn increases the direct revenue for the platforms, such that a platform firm (Microsoft, in this example) considers the creation of even more custom application programming interfaces (APIs), i.e. increase the scope of offerings, to attract a larger number of ISVs. But as the number of custom APIs goes up, the cost of supporting ISVs goes up, and if the licensing fee from the ISVs is not growing, the profit margin go down and the platform looks for a more focused development strategy by reducing the number of ISVs.  These tradeoffs between revenue and costs may require the platform firm to reduce the amount of flexibility offered by customizing the APIs to reduce the numbers of ISV partners by following a focused API strategy (Anderson & Parker, 2013).

One caveat about this process is in order: the BMC provides a static picture, whereas the causal loops provide a dynamic understanding of how the logic may evolve. Most PMs think about the BMC, and then simply make static comparisons of the elements (e.g. additional key activity vs. cost structure). In our experience, a fuller causal-loop driven analysis is more useful for a “systems thinking” view of how the BMC elements may interact over time. But, such thinking also requires more work and sophistication. Some PM teams stick with static BMC comparisons, and do not think through causal-loop dynamics.

In summary, the BMC can be used to map the overall business strategy (e.g., scale vs. scope) of the platform, and key elements of the BMC such as the number of partners, the value proposition, cost structure and revenue streams. PMs can use BMC analyses to understand the elements of an existing business model (i.e., potential partners or competitors) by reverse engineering it. Such analyses may be used to inform dissenting members of a PM team as to why a particular decision is being made (e.g., to secure a larger or a smaller number of partners). In such a case, a PM may either use internal or external sources of information to fill in the elements. The PM may need to make assumptions about some of the relationships between any two boxes of the BMC (e.g., key activities and cost structure or value propositions and revenue streams) and make inferences about the firm’s overall business and product strategy. These inferences may be updated by collecting additional data on the assumed relationships. Finally, the BMC box structures and the causal loop diagrams are just one possible mechanism for qualitative depiction of business model dynamics. Other representations such as the Balanced Score Card (Kaplan and Norton, 1996) and System Dynamics Simulations (Sterman, 2000) serve a similar purpose.  In Part V, we will illustrate how to look at these tradeoffs quantitatively by setting up a profit and loss analysis.

(Discussion: Interactions across elements of a business model)

References

Anderson, E. G., & Parker, G. G. (2013). Integration and co-specialization of emerging complementary technologies by startups. Production and Operations Management, 22(6), 1356–1373.

Blank, S. (2014, Oct. 24). The business model canvas gets even better – Value proposition design [Blog]. Retrieved from https://steveblank.com/2014/10/24/17577/ 

Chandler, A. (1994). Scale and scope: The dynamics of industrial capitalism. Cambridge, MA: Belknap Press of Harvard University Press.

Coren, M. (2016, Aug. 26). The highest paid workers in Silicon Valley are not software engineers. Quartz [Blog: Show Me the Money]. Retrieved from https://qz.com/766658/the-highest-paid-workers-in-silicon-valley-are-not-software-engineers/ 

Davenport, T. (2014, March 3). Big data at work: Dispelling the myths, uncovering the opportunities. Brighton, MA: Harvard Business Review Press.

Gnanasambandam, C., Harrysson, M., Srivastava, S., & Wu, Y. (2017, May). Product managers for the digital world. McKinsey&Company. Retrieved from www.mckinsey.com/industries/high-tech/our-insights/product-managers-for-the-digital-world

Horowitz, B. & Weiden, D. (1998, April 1). Good product manager, bad product manager. Khosla Ventures [Blog]. Retrieved from http://www.khoslaventures.com/good-product-manager-bad-product-manager 

Kaplan, R. S., & Norton, D. P. (1996). Linking the balanced scorecard to strategy. California Management Review, 39(1), 53–79.

Layton, S. (2009, April 21). Blue ocean vs red ocean strategies. Retrieved from http://www.corporatestrategy.com/red-ocean-vs-blue-ocean/

Kim, W.C. & R. Mauborgne (2005). Blue ocean strategy: From theory to practice. California Management Review 47(3), 105–121.

Martin, R. L. (2009). The design of business: Why design thinking is the next competitive advantage. Boston, MA: Harvard Business Press.

Nagaraj, V. and D. Billings (2002). EnCORE-EDGEing Your Strategy. http://www.top-consultant.com/ask_a_guru/article.pdf

Osterwalder, A., & Pigneur, Y. (2010). Business model canvas. Self-published. Retrieved from https://strategyzer.com/canvas/business-model-canvas

Porter, M. (1996). Competitive Strategy: Techniques for analyzing industries and competitors. New York, NY: Free Press.

Prahalad, C. & Hamel, G.  (1990). May–June. The core competence of the corporation. Harvard Business Review, 79-90. 

Sterman, J. (2000). Business dynamics: Systems thinking and modeling for a complex world. Boston: Irwin/McGraw-Hill.

Tsuchiyama, R. (2011, Feb. 14). The product manager as the digital industry’s rock star. Forbes. Retrieved from https://www.forbes.com/sites/raytsuchiyama/2011/02/14/the-product-manager-as-the-digital-industries-rock-star/#2418b2625983 

Venkataraman, V. (2017). The digital matrix: new rules for business transformation through technology. Vancouver, BC: LifeTree Media.  

Pages: 1 2