How to Build a Product Management Team from Scratch

The Optimal Customer-Driven Release Frequency Formula

Summary

  • Why does understanding optimal release frequency matter?

    • Understanding and acting upon what drives an optimal release cycle ensures that the value your team delivers is ultimately absorbed and utilized. 

    • Delivering value at a pace that stakeholders are unable to utilize is only marginally better than not delivering that value at all, with the marginal value difference consisting of the hope that those stakeholders will utilize that value at some point in the future. 

  • The Optimal Customer-Driven Release Frequency Formula

    • Determining how frequently product and engineering teams release changes can be a contentious topic within organizations, but it should ultimately be based on two values, which are themselves multi-factorial.

    • The following formula optimizes for product success over the long term, and while release cycles can be based upon other factors, those factors are typically short term/single objective focused instead of process focused. 

    • At the highest level:

      • Optimal Release Frequency = (Average Time Required for Internal Stakeholders to Absorb Releases + Average Time Required for External Stakeholders/Customers to Absorb Releases)

        • Ex = 6 weeks for Internal + 6 weeks for External = 12 Week Release Cycles

        • Note - Sometimes these activities can be done in parallel.

      • Average Time Required for Internal/External Stakeholders to Absorb Releases are each composed of time required for [Training + Documentation Updates + Usage]

    • Full Formula 

      • Optimal Release Frequency = 

        • Internal Stakeholder Training + Internal Documentation Updates + Internal Usage

        • External Stakeholder Training + External Documentation Updates + External Usage

  • Incorrect Drivers of Release Cycles

    • Release cycles are often principally driven by a number of reasons other than the above, which are sub-optimal in a number of ways and explored further in the discussion section. This doesn’t mean the following factors shouldn’t be considered, simply that they should not be the key drivers over the long term.

      • Internal Process - Agile says we should release every 2/4/X weeks, so that is when we’ll release!

      • Publicity/Marketing/Sales / Event Driven - We have a quarterly/semi-annual/annual conference coming up, we need new features to talk about!

      • Staff - We have enough staff to release every 2/4/X weeks, so that is when we release!

      • Competitors - Our competitors sell their customers on new features every 2/4/X, so we’ll do that too!

  • Optimal Customer-Driven Release Cycle Cheat Sheet

    • Includes formulas and factors related to the optimal CDRC (PDF), (PNG), (PPTX).

Detailed Discussion

Far too often, product and engineering teams will ship features and releases at a pace that is inconsistent with the goal of delivering the maximum amount of value to both their internal and external stakeholders. This is surprising in the sense than good product teams are theoretically the “voice of the customer” and are responsible for understanding what solutions will deliver the most value. Ultimately, the ideal release cycle delivers value at an organization-specific pace that internal and external stakeholders can maximally absorb and utilize. Analogous to the shift towards customer driven development, we focus here on shifting closer to customer-driven release frequency.

Just as it is critically important for product and engineering teams to identify the right problem and the right solution, it is equally important that those teams ensure customers and stakeholders are set up to successfully utilize those solutions upon delivery. If the release cycle is too rapid, customers and stakeholders will simultaneously be frustrated at the rate of change and their inability to learn how to leverage the new features. If the release cycle is too lethargic, customers will churn and stakeholders will yearn to play on an innovative team. 

Finding an ideal release cycle involves exploring a number of different drivers that are specific to your stakeholders and your customers, which are primarily driven by how quickly those stakeholders can utilize the value you create. These drivers converge on an optimal customer-driven release frequency formula. In addition, there are influencing factors that should be considered in determining your ideal release cycle, but should not be driving its pace over the long term.  Let’s explore the drivers that make up the optimal release frequency formula alongside each of the primary influencing factors. 

  • The Formula

    • Optimal Customer-Driven Release Frequency = Average Time Required for Internal Stakeholders to Absorb Releases + Average Time Required for External Stakeholders/Customers to Absorb Releases

    • Average Time Required for Internal/External Stakeholders to Absorb Releases are each composed of time required for [Training + Documentation Updates + Usage]

  • Drivers

    • Average Time Required for Internal Stakeholders to Absorb Releases is composed of:

        • Training - Is each internal department aware of the new changes and how to support customers?

        • Documentation Updates - Is each artifact used by the organization properly updated to reflect the new changes?

        • Usage - Are employees using or interacting with the new changes? Have they incorporated them into their workflows?

    • Average Time Required for External Stakeholders/Customers to Absorb Releases is composed of:

        • Training - Do customers understand how to use the new features? 

        • Documentation Updates - Is each artifact used by the customer properly updated to reflect the new changes?

        • Usage - Are customers using or interacting with the new changes? Have they incorporated them into their workflows?

  • Influencing Factors

    • Internal Process - Sticking to a release cadence or process that delivers change at an arbitrary, albeit consistent, time interval is largely unhelpful if customers and stakeholders can’t absorb the delivered rate of change. Many teams marshal continuous delivery or two week release cycles as proof that they are delivering significant value to the business without discussing or disclosing how much of what was shipped is actually being utilized. Shipped Value != Absorbed Value.

    • Publicity/Marketing/Sales / Event Driven - There is absolutely no product and engineering team on earth that can avoid the occasional release that is scheduled principally around a specific event or client. There will be big clients your company needs to win and features built specifically for tradeshows. It is important to accept that these situations will occur, understand that these events are exceptions to your ideal release cycle, and explain to stakeholders why these occasions are in fact exceptions to the optimal customer-driven release cycle your team has so carefully determined. 

    • Staff / Empire Building - The size of the product and engineering organization can be a factor when it is too large or over-resourced relative to the products it owns. As discussed previously in Empire Building, product and engineering teams will grow over time (Great!), but the products they are responsible for do not necessarily need to grow or change at a similar rate. In an ideal world, those product and engineering resources are reassigned to new products. In the real world, those resources stay put and justify their existence by continuing to release new features that are unnecessary at worst and marginally helpful at best. In this case, the optimal release cycle has likely shifted and product/engineering resources must shift as well. 

    • Competitors - As software consumers have become more aware of the SaaS business model, rate of value delivery and agile development have become points of differentiation in the sales process. This is unlikely to change at any point in the future as it would require massive customer re-education by sales teams that are incentivized to do precisely the opposite. It is your responsibility as the product and engineering team to educate stakeholders on the rationale behind your release frequency and the data that it incorporates. Do not assume that even though a 6 month release cycle is ideal for your customers that those same customers will automatically admit to that fact or appreciate your rationale. 

Examples & Suggestions

While your release cycle will be driven by the values specific to your customers and stakeholders, there are several rules of thumb that can be helpful, all subsequently discussed as well as summarized in the diagram below.

  • Product Complexity - As product complexity increases, the length of your release cycle will likely naturally increase. This is primarily due to the multiplicative factor of product complexity, in that for each required change management activity typically required for a new release (Training, Documentation, Usage Monitoring), each of those activities will increase in proportion to the complexity of the product. An example of this can be seen in comparing the Uber application to Facebook - both are consumer facing applications, but Uber has a significantly narrower consumer facing scope than Facebook, which allows more frequent changes around that scope.

  • Customer/Stakeholder Dedication to Product - Release cycles can be shortened if you have a fanatically dedicated customer base, either due to a natural monopoly or the criticality of your software to your customer’s tasks. Dedication matters because it will increase the rate at which customers can and want to utilize the changes that your team ships. A great example of this is Adobe, whose products are all mission critical to the media production industry and are natural monopolies in their space. 

  • Customer/Stakeholder Industry Regulation - If your industry is heavily regulated, there may be a maximum rate of change that your customers can legally or logistically absorb. This is nearly zero for consumer facing applications whereas it tends towards infinity for nuclear power plant operating systems. This point is less a commentary on whether the regulation is justified or not, and more focused on determining what effect it will have on your release cycle. 

  • Dedicated Change Management Resources - If your company has an appreciation for change management and appropriately staffs training/documentation resources, it may be possible to dramatically shorten your release cycles. For example, if your customer success team is running a webinar on a regular basis to educate customers on upcoming and already released features, your organization can realistically ship change at a much faster pace than if change management is primarily handled by sending out educational emails that customers and stakeholders don’t read. 

The main objective is to ensure that the value that you ship is approximately equal to the value utilized by customers and stakeholders. If it isn’t, resources are being allocated in a sub-optimal fashion, and your team should consider changes to one or more of the variables discussed above.

Product Management Due Diligence List

Summary

  • Conducting due diligence is a skill typically relegated to consulting and investment firms, but it is equally as critical to product managers when evaluating products that they may decide to buy versus build or partner

  • While due diligence typically encompasses all divisions at a given company (financial, legal, sales, marketing, engineering, etc.), we’ll focus on conducting diligence on software products from the perspective of a product manager. 

    • Note that despite this being a product focused list, we will necessarily wander into other divisions of the company due to the nature of product management’s widespread interaction and influence. 

  • This list aims to be as comprehensive and exhaustive as possible, so as to be useful not only during diligence but also as a check for product teams as they build products to ensure they are thinking objectively about their product’s success.

  • Even though lists are difficult to summarize by their nature, the key question to continue to ask about the aspect of each product during diligence is simple - why?

  • Similar to the 3 Levels of Product Thought, diligence can be thought of similarly:

    • Phase 1 - Discover the Current Product 

      • The objective in this stage is not to form an opinion, your role is that of a detached and curious observer intent on understanding the product in its current form. 

    • Phase 2 - Understand the Product’s History

      • The objective in this stage is to understand why the product acts / feels / was designed / was priced / was coded / was released / was sold / was marketed in the way that it has been. 

      • Historical product choices were made for a reason, those decisions and their rationale may be illogical or irrelevant, the goal in this stage is to understand how and why those decisions were made, and begin to form an opinion as to whether those were the right ones. 

    • Phase 3 - Form an Opinion on the Product’s Future 

      • The objective in this stage is to incorporate your understanding from Phase 1, and your historical research from Phase 2, in order to form an opinion on the product’s future.

      • Just as we asked a series of questions in Phase 1 and 2, we will now be providing our opinion in order to answer those exact same questions. 

      • These answers will help us determine if this is truly a product our company wants to purchase. 

  • Downloads - I’ve converted the framework and question lists into downloadable PDF and Word versions.

Detailed Discussion

As the overall due diligence framework was discussed in the summary, we’ll use the detailed discussion section to break down in further detail the exact questions I would, and have used, to evaluate products for potential acquisition. 

The framework above is how you should be thinking about and evaluating the information that you obtain with the following list of questions. Ideally you are using the following questions to build your layers of understanding, but you’ll ultimately need to organize the information provided in to the framework above as it is almost always provided in an ad hoc manner

I have historically tried to pre-solve this problem by structuring my questions around each phase, asking one after the other, but product management is complicated, and answers will frequently interweave information that will be valuable at each stage of your understanding. 

Given the reality of the diligence process, your role as a product manager or analyst is to first capture all the information required and then organize it in to the above framework. In my experience, it is virtually impossible to ask the following list of questions so that the verbatim output and answers are neatly formatted and analyzed. Organizing the information is half the value provided during diligence. 

  • Product Management Due Diligence Question list

    • Customer Observation and Interview - Minimum 10 customers. 

      • While it can sometimes be a challenge to convince the company to let you sit with their customers, it is absolutely critical to understand from a customer perspective how that product is utilized. 

        • One “hack” around the difficulty in obtaining customer access is to watch YouTube tutorials of the product from individuals not associated with the company. These tutorials will often illuminate the flaws in the product that only users will uncover. 

      • Ideally, you interview and observe customers from each of the customer personas and segments discovered during diligence, this can help your team understand where potential opportunities / gaps remain. 

    • Customer Product Experience

      • In addition to watching the customer use the product, it is important to understand their qualitative experience about the product as well. 

      • Feelings

        • How does the product make them feel? Efficient? Happy? Sad? Annoyed? Ignored? 

      • Onboarding

        • How are customers onboarded? Is this automated? Why or why not? Is this the right approach? 

          • Most B2B companies have manual onboarding steps, most of which can be automated at no cost to the customer experience 99% of the time. This is one of the most straightforward product improvements to try to find. 

        • What is each customer’s time to value (The time it takes from when they are sold to when they actually derive value from the product)? Break out by persona / segment / cohort?

          • This can be surprising as well if companies have long sales and installation cycles. Massive improvements can be had in customer satisfaction by fixing this step. 

      • Billing

        • Relating to pricing, how do customers actually pay for the product? Credit card / ACH / Invoice / Check?

        • Are there any issues with billing? Are customers happy about it or would they prefer another way? 

          • You can often produce huge improvements in customer product satisfaction by simplifying the billing process. One would think that companies would be incentivized to make it as easy as possible for customers to pay, but this is not always the case. 

      • Support

        • How are customers supported? Email / phone / chat / text / social channels / in person / support system (Salesforce / Zendesk)? Are these channels good / bad / worthwhile?

        • Is there a public knowledge base? Is it used? Why / why not?

        • Are customers happy with the responses they get? If not, why? If so, why?

        • How, if at all, does customer support relate to customer churn? 

      • Contracts & Service Level Agreements

        • What is the contract signing experience like? What are sample contracts for each persona and customer segment? 

        • What are customer service level agreements? Are they profitable for the company? Are they too strict / too lax? Have they been routinely violated?

        • What are the termination dates? By cohort / product / persona / segment? Is there a termination “cliff” where many contracts come up for renewal at once? 

      • Localization

        • Are all customers English speaking? Are there localization issues? Would the product perform better if localized? Would it reduce complexity to have one product language?

    • Product Team

      • Who are the members of the team? Are they effective? What performance review process exists? Is it effective? Do you want to retain all / some / none of the product team? 

      • What is the product culture? Is it the same as yours? Is it focused on growth / stability / security? What incentive scheme does it operate under? Is the team effective? Will the culture merge with yours? 

      • How is knowledge shared and capture? How are features and product artifacts managed? 

      • Is the product team all in one office? Different offices? Are they remote or in office? 

    • Product Artifacts

      • Competitive Landscapes

        • Who are the primary competitors in the space? 

        • Who are the secondary competitors? Are they worth buying? Why are they secondary? 

        • Who does your sales team see in the sales process? Who do they lose against? Who do they win against? Why do they lose? Why do they win? 

        • Are their substitutable goods / services / products that have been ignored? 

        • Are there competitors that the company is losing against that they are not tracking? Are there competitors on the horizon?

      • Market Maps

        • Market maps are different than competitive landscapes as they include products and services that are in adjacent spaces and industries. These are important to understand both for future product opportunities as well as potential competitors.  

        • What is the space that the company operates in? Is it one of fierce competition (productivity tools) or quasi-monopoly (Uber / Lyft)?

        • Why are they in that space?

          • Most would assume that the company operates in a space that is optimal which is not always the case. Companies can long operate in business spaces and segments that are sub-optimal for a multitude of reasons, some rational, some less so. 

      • User Stories

        • How does the product team produce their user stories? Obtain examples for a recent release. 

      • Customer Personas & Segments

        • Who are the customer personas? What do the product’s customers look like? 

        • What are the customer segments? Are they the same as the personas or different? Why are they different?

      • Product Vision

        • What is the product vision? Why is that the product vision? Is there a product vision or is there just a list of features to be developed?

          • Having a product vision incorporates all of the elements discussed in this list to produce the why behind the value to be delivered to customers.

          • Many companies simply have a long list of prioritized features that are divorced from or ignore the ultimate value they provide to the user. 

      • Go To Market & Target Market Analysis

        • How has the company gone to market with new products and features? 

        • What is the rollout process? For product? For engineering? For marketing? For sales? For services? For customer success?

          • It is important to ask each of these departments independently and without product team members in the room. The goal here is to understand from each division’s perspective how the go to market process works without product influence. 

      • Pricing

        • How are products priced? Monthly / Quarterly / Yearly? Recurring subscription / one time payment / combination? 

        • Are there discounts given? Why are there discounts given? Should they be given?

          • Education / military / special segment discounts?

        • Are products sold at list price or are there discounts given? If so, what are they and why are they given? To what personas / segments?

        • How are those prices displayed to customers? Are they on the website? Do customers have to call or request a quote? How long does it take for a customer to obtain a price for a product?

        • Are the prices reasonable or should they be lowered / raised?

          • It is shocking the level of leverage companies can obtain by simply raising their prices. While this can have many effects, in general it will weed out the customers that are most costly to you / the company and keep the most profitable customers to you / the company. This occurs because raising prices forces those customers to evaluate whether your solution is really worth paying for on a recurring basis.

      • Product & Feature Priorities

        • Relating to product vision, what are the current priorities for each product and how are those broken down into features? 

        • Why are they the current priorities? How were they prioritized (Value, CEO/VP Edict, Big Customer Request)?

          • How products and features are prioritized will tell you a great deal about how products are built, how the product organization functions, and where power is held within the organization. 

      • Product Roadmap - 3 / 6 / 12 Month

        • Relating to product and feature priorities, how do those priorities come together to form the product roadmap for the next 3/6/12 months? 

        • Where is the product roadmap stored? Who has access to it? Why is that the case? 

      • Partner Ecosystem

        • Who are the current partners? What functionality do they provide? Why were those partners selected over other partners in the space? 

        • Are any of those partner solutions better integrated through either building those solutions or acquiring them?

    • Data & Metrics

      • Cohort Analysis

        • What are the retention rates for both customers and revenue, on a per product / customer segment / user persona basis?

        • If you gave me one data point about a product, this would be it. Nearly every other issue can be fixed in this list, but if you can’t retain customers and/or sell them more over time, the product has fundamental issues. 

      • Customer Acquisition Cost - CAC

        • How are customers acquired? What channels? At what cost? Are some channels better / worse than others? Are some channels not being used? 

      • Customer Life Time Value - CLTV

        • What is the lifetime value of your customers? By segment? By persona? 

        • Are all of these profitable? If so, could they be more profitable? If not, why not? 

          • This is another high leverage question, more often than not, there are opportunities to cut underperforming customer segments and raise prices on better performing segments. 

      • Product Usage Metrics

        • How is the product being used? How is that being measured? Time on site / DAU/MAU, core actions taken? 

        • What tools are used to measure this (Google Analytics, Optimizely)? Are staff trained on these tools? Why / why not? 

    • Technical Diligence

      • While technical diligence is an entirely different essay, it’s worth considering some of the questions that can affect the product. 

      • 3rd Party Resources

        • Does the team rely on any consultants? Have they signed the appropriate legal agreements (Ex - IP Assignment, NDA)?

        • How much of the product was developed / designed in house vs outsourced? 

          • This can matter if you are buying just the IP or the team as well.

      • Engineering Process

        • What process does engineering run on? Agile? Waterfall? Hybrid? Is it effective? Why / why not? 

        • Are there dedicated test and staging environments? If so, how are they used? If not, why not? 

        • What systems do you use for code collaboration and revision? 

        • How are secrets (AWS Keys, Encryption Keys, Logins) handled and shared? What are your access controls? What personnel have access to these items? An ability to change them? 

        • Does each product manager have their own engineering resources? Or do multiple product managers assign tasks to one engineering team? 

      • Data Handling, Backup, Recovery

        • What is your disaster recovery plan? Has it been tested? When was it tested? What was the result? 

        • How is data backed up? Has it been tested? When? What was the result?

        • How is data secured? Have you ever conducted security audits? If so, what were the results? If not, why not? 

        • Where is customer data stored? Cloud / on premise / hybrid? 

      • Technology Stack

        • What languages is the product built with? Does your company have expertise in these languages? If not, are you prepared to obtain them? If so, is the level of expertise the same?

          • This is a critical question, as often tech being on a different stack can rule out an acquisition entirely. 

Deciding Whether to Buy, Build, or Partner for Product Solutions

Summary

  • After the decision has been made that solving a specific business problem for your clients is worthwhile, the next decision centers on whether to solve that problem by buying a solution (through acquisition, off the shelf technology, or consultants), building a solution internally (via your own team), or partnering with another company (which could ultimately lead to an acquisition). 

    • This decision flow is summarized as:

      • Go/No Go on Specific Business Problem -> (BBP)

        • Buy

        • Build

        • Partner

  • While the details discussed below explore the nuances of BBP, simply being aware of the fact that there are three possible methods that can provide a solution to your customers, and that they are worth investigating versus assuming that the only way is to build it yourself, can provide enormous value to your product and engineering teams. 

    • Your goal is to solve business problems for your customers. 

    • Given a stable solution, the manner in which that problem is solved can be/should be immaterial to them. 

  • The central assumption that BBP rests on is that internal resources are limited and that taking advantage of the specialization inherent in our economy is worthwhile (that specialization results in lower costs). 

    • This is particularly relevant when attempting to provide features or solutions that you believe serve a temporary market need, but may ultimately be deprecated, saving your team from additional product complexity and deprecation time. 

  • The detailed discussion of each decision path (Buy, Build, Partner) is summarized via 1-pager PDF/PPTX to print and share (PDF) (PPTX).

  • Due to this post’s length, it can be downloaded as a PDF here for easier reading.

Detailed Discussion - Buying Solutions

  • Buying Solutions

    • Note that buying technology companies will be expanded upon, but this covers acquisitions from a BBP perspective of providing solutions to customers, not the nitty gritty of what it takes to acquire a company.

    • When It Can Make Sense

      • Future Industry Direction - Buying a solution can be effective if you believe the industry that you operate in is headed in a specific direction that you are incapable of innovating into internally. Given the significant costs associated with acquisitions both in terms of financial resources and culture/staff redundancy, making an acquisition to obtain a solution that you believe may not have staying power typically doesn’t make sense. Acquisitions should primarily be long term investments, not to build empires or capitalize on short term market whims. 

      • Lack In House Expertise - Acquisitions can also make sense if your team lacks skill sets in certain areas, but if the primary reason for an acquisition is talent, it may be better to examine your hiring pipeline to better understand whether there is a root cause for talent deficiency. If the reason is a misunderstanding of a fast moving market trend, an acquisition could make sense, if it is because your hiring processes are in disarray and top candidates are uninterested in offers you’ve made, acquisitions will not fix the root issue. 

      • Time to Market Matters - In certain scenarios, buying a ready made platform or solution can allow your company to provide a solution much more quickly that it could if it were to build it using internal resources. The value of speed in this case needs to be weighed against the acquisition’s integration and financial costs. 

      • Possibility to Upsell/Cross Sell Customers - One of the most commonly underutilized reasons is that your acquisition target has a customer base of limited overlap and that your company will be able to upsell or cross sell those customers on your own solutions, while also upselling / cross selling your current customers on your acquisition’s solutions. If done correctly, this can add significant top and bottom line growth. 

      • High Certainty Regarding Solution Value - Given the level of time/money/resources required to successfully acquire and integrate another business, you need to have a high degree of certainty that the solution that is being acquired will do exactly what you require it to do. This is why it is typically better to Partner first, complete the integration, and test its value before acquiring the company outright. 

      • Cost Structure Synergies - While we primarily focus on product related reasons for acquisitions here, there can be cost structure synergies if your target has heavy finance/legal/marketing investments that you can more readily scale across your entire customer base. 

      • Inability to Reinvest Cash Successfully (Organic Growth) - Again, while we focus primarily on product related reasons here, if your company is operating in a mature market and has limited avenues to invest in organic growth, acquiring a company in a complementary space and reallocating resources around that opportunity can make sense. 

    • Pitfalls to Avoid

      • Acquirer / Acquisition Founder Vision Differences - We have all seen it a hundred times: Founder sells his company to a larger acquirer, and as soon as the vesting/earn out period is over, leaves for greener pastures. While there can be many reasons why this occurs, the most significant is because the vision for that technology/company that was presented to the founder during due diligence/acquisition has changed or was outright false. It is less of a problem if you, the acquirer, understand and present those differences to the founding team during diligence, but proposing one vision and pushing another can result in irreconcilable differences and significant intellectual property leaving before the ideal time. 

      • Cultural Differences - Based on my own personal experience, culture is often written off as something that is immaterial or inconsequential to the success of the acquisition. This is a categorically false assumption because the degree to which  your culture and the acquisition’s culture fit together will dictate how well the combined entity performs on a daily basis. A poor culture fit will cause significant micromanagement, high employee turnover, and high customer churn. If the cultures don’t match, and the acquisition is based on anything other than intellectual property, it will likely be difficult to integrate your new employees and your finance team will soon be writing off significant amounts of acquisition goodwill. 

      • Different Office Locations - Hand in hand with culture, different physical locations can make the integration of your acquisition difficult. Distance increases reliance on written and telephone communication which can often result in significant misinterpretations. Understand that an acquisition in a different time zone, let alone a different country, will require large amounts of facetime, both initially and over time. 

      • Technology Stack Differences - Purchasing companies that have built their technology on a different stack than your own will increase your product’s complexity immediately and for as long as that product is active. If your company does not posses expertise in this tech stack, the challenge to integrate can be even greater, and as a result, a partnership will likely be a better choice. 

    • Skillset Required

      • While the skillset required will vary depending on the size of the acquisition, it is important to have someone within your company that has completed or worked on mergers and acquisitions at an organization dedicated to that activity. This could include prior investment bankers/consultants/private equity investors or anyone that has been part of a deal process previously. 

      • The difficulty of acquisitions, even of small enterprises, should not be underestimated. Among many things, your team needs to understand corporate structure, tax law, stock and option agreements, real estate agreements, employee agreements and how each of those individual issues affects the ultimate goal of the acquisition. 

      • As a consequence, what was originally a product management decision can shift into an organization-wide question of whether this acquisition makes sense for the business as a whole because of the different internal resources you will need to utilize to have a successful acquisition - it will not just be product management team members. 


Detailed Discussion - Building Solutions

  • Building Solutions

    • When It Can Make Sense

      • Tight Integration Requirements - One of the most challenging aspects of acquisitions and partnerships is that to succeed, extensive integration work is typically required. Solutions that are less modular and require comprehensive integration work are typically best built by your internal product and engineering teams. Internal teams will have lower coordination costs in understanding the desired end product while already possessing familiarity of existing infrastructure and how it can be best modified. 

        • A general rule of thumb is that the more complicated and integrated a solution would be for an internal team to build, that time/complexity estimate is the baseline from which an outsourced/acquisition solution should be estimated. 

          • External Estimate =  Internal Estimate * Outsourcing Multiplier

          • (External Estimate) is almost always > (Internal Estimate) for projects with tight integration requirements

        • In complex projects, estimates typically only increase when involving outside organizations that are unfamiliar with your customers, data and infrastructure. 

      • Potential for Solution to Change During / After Development

        • If your team is practicing some form of agile / responsive development, it can make particular sense to build a solution if you believe the form that solution will take (the end result or output) will iterate and change during the course of construction. 

          • There is a possible exception to this, which is if you have a high degree of confidence in the end solution,  but a low degree of confidence in the best way to obtain that solution. 

          • In this scenario, multiple partnerships that explore different means to an end can be more efficient than exploring each of those pathways with your own teams and resources. 

        • Rapid feedback loops are best served by teams closest to the customer, which in most cases, will be your internal product and engineering teams, not external consultants or partners.

      • Proprietary Data Required

        • As GDPR has illustrated, storing and processing data will likely be a greater liability for technology companies in the future. If a product requires extensive analysis or use of internal proprietary data, the legal documentation required to allow partners access to this data can often be prohibitive from a time to market perspective (For example, by the time you have hashed out your legal agreements, it may have been easier and simpler to build that solution internally).

        • It is also worthwhile to understand the company wide risk and liability created when opening up your internal data sets and systems. Despite your best efforts, as soon as your data sources are opened in any capacity, there is now a non-zero chance that a server is misconfigured or an AWS bucket is left open. 

      • Possess In House Expertise

        • While superficially obvious, I have personally seen management teams overrule their own product and engineering organizations despite their possession of the requisite staff and knowledge. 

        • If you already have the skillset required to build your desired solution, it likely makes sense to build the solution internally. 

        • The challenge in this scenario is not whether it makes sense to build it internally, it is best communicating to non-technical stakeholders why it makes sense to do so, if for any reason it appears otherwise

      • Lack Skillset/Budget to Buy/Partner

        • If your organization lacks the skills or staff required to buy or partner, it is far better to default to building that solution internally than to make an acquisition or build a partnership incorrectly. 

        • It is not a judgement or admission of incompetence of your company if you feel ill prepared to partner or acquire. Both of these activities require substantial expertise and resources to complete correctly, and your company will likely be far better off avoiding both activities until it is truly ready. 

      • Potential for Stakeholder/Board Disagreement

        • Echoing the issues with proprietary data management above, the level of discussion required to acquire a company is greater than that needed for a partnership which itself is greater than the amount needed to build the solution internally. If the project has a high chance of being torpedoed in acquisition or partnership form due to political reasons, better to attempt to build that solution internally. 

    • Pitfalls to Avoid

      • Pitfalls to avoid when building internal products are the subject of a number of dedicated posts, which you can find referenced in outline form here.

      • Summarized

        • Over / Under Estimation of Work Required

        • Poor Coordination with Other Stakeholders / Departments

        • Over / Under Estimation of In House Talent / Expertise

        • Short & Long Term Budget / Resource Cuts

        • Employee / Knowledge Retention

    • Skillset Required

      • The skillset required to construct a capable internal team is the subject of a number of dedicated posts, which can find referenced in outline form here.

      • Summarized

        • Fully functional/capable product management and engineering teams. 


Detailed Discussion - Partnering to Obtain Solutions

  • Partnering to Obtain Solutions

    • When It Can Make Sense

      • Acquisitions & Partnerships - Many of the reasons discussed previously that make acquisitions valuable can also apply to partnerships. 

      • Possibility to Upsell Customers

        • Just as customer upselling is a major benefit to acquisitions, it can be the determining reason to create a partnership if there is limited customer overlap or the partner’s customers are in a strategically valuable vertical. 

        • For partnerships however, customer access is typically bidirectional, so if one of the partnership’s goals is customer upselling and access, your team should be prepared to provide the same. 

        • This can have far reaching ramifications for departments outside of engineering and product, such as sales, marketing and customer success. If your team decides to take this approach, it is your responsibility to set those teams up for success, as they will be the recipients of the partnerships downstream output. 

      • Temporary Demand for Solution

        • Partnerships can make sense if your team is unsure of how long the solution will be demanded by clients and/or the marketplace. 

        • There are certain scenarios where it makes sense to “lease” the solution via partnership, and while there is greater integration work, your company can avoid creating a solution that would ultimately end up as additional technical liability. 

      • Simple Solution, Complex Implementation

        • Another scenario in which a partnership can make sense is when the end result, while valuable to your clients, is not valuable enough from an ROI standpoint to justify building it internally. This could occur if building the solution is extremely complex and/or requires significant fixed costs while the amount you can charge your clients for providing that solution is minimal. 

        • Another method of thinking about this scenario is that your competitors and partners may accept lower margins than your company for any number of reasons, which can be strategically advantageous to your organization in this scenario. 

      • Staff & Integration Commitment to Ecosystem Construction

        • In some companies, particularly marketplaces, it can make sense to build out an ecosystem of partners that provide solutions to your clients. If this is a strategic imperative for your company, and you have been given the resources to properly build partner relationships and incorporate their technology, smaller projects can have a much higher ROI if they are provided by partners. 

        • The concept of a Partner Product Manager, when it makes sense to build out a partner ecosystem, and the resources required to do so are detailed more thoroughly in a separate post. 

      • Ability to Compete Against Larger Players

        • Partnerships can make sense if your company is competing against a more dominant competitor in a specific area that is unconquerable individually. A theoretical example of this might be Google and Costco teaming up to provide technology and shopping to each of their customers. Each business has limited overlap/competition in the products it individually sells, and to better compete with a fully integrated competitor like Amazon, a partnership could help significantly. 

      • Diligence Potential Acquisitions 

        • One of the best reasons to form a partnership is as a method of due diligence for an ultimate acquisition. Even the best investment banking and private equity professionals can’t uncover how well a company day to day will perform like a partnership. 

        • In a partnership done correctly, your company will necessarily do nearly the same work as an acquisition in order to fully utilize the partners capabilities. It is a great way to preview working with that partner’s employees, founders, clients and technology without needing to buy the company outright. 

      • Network Effects / Winner Take All Dynamics

        • Partnerships can also make sense if your company would like to expand into a business vertical that requires network effects. 

        • For example, were Hertz to go into ride sharing, it would make more sense for it to partner with Uber and Lyft in some fashion rather than create their own ridesharing service due to the driver/passenger network effects that they would need to create from scratch. 

        • Entering a network effect market unilaterally typically only makes sense if your company already operates at significant scale.

          • Ex - Google building out its autonomous car division, Waymo, with a corresponding ridesharing service. Google will likely be successful, all else equal, because of its scale in other businesses and its ability to directly interact with millions of consumers.

    • Pitfalls to Avoid

      • Partnerships share the pitfalls of acquisitions discussed above, but have one unique pitfall of their own. 

      • Partnership Exclusivity

        • In an ideal world, all partners would form exclusive relationships with you without requiring you to form any kind of exclusive arrangement with them. 

        • In reality, this scenario never occurs, and exclusivity can be a touchy, but important, subject to broach with your partners. 

        • Mutual exclusivity, where you/your partner do not interact with any of each other’s competitors, can make sense if you believe:

          • (A) - There is a high chance that your competitors want to work with this partner, and an exclusive partnership is a way of preventing that from occurring. 

          • (B) - Your organization has done its homework and believes this partner to have the best solution on the market. 

        • If exclusivity is an objective of the partnership agreement, a generally helpful route is to obtain exclusivity even if it is for a short period of time, and have that exclusivity auto-renew unless cancelled by either party. If the default is exclusivity, in most scenarios it will continue and it will also provide an uphill battle to a competitor that wants to work with your partner. 

        • If your team is unaware of exclusivity as a point of negotiation, a competitor could, and very likely will, form an exclusive relationship with your partner and cut you out, resulting in significant technology un-integration issues and customers who suddenly lose access to a service they assumed was steady.

    • Skillset Required

      • While the skillset required will be discussed in greater detail separately, partnerships generally succeed when there is a dedicated partner product manager that manages partnerships just like internal products. 

      • In other words, a headcount focused around ensuring those partnerships are a success, that they are sold to clients, that they have their own KPIs, and that they have their place on the product backlog to ensure proper integration. 

Industry Examples

Let’s walk through a couple of examples that use the above frameworks:

  • Buying Solutions

    • Analytical Disclaimer - Based on my experience in private equity, it is incredibly difficult to analyze mergers and acquisitions based on the information released to the public. The story reported is often a small fraction of the work, diligence and information available to the acquirer and the company being acquired. That said, we will walk through two examples utilizing the framework discussed above. 

    • Good Example - Twilio’s Acquisition of SendGrid for $2B (Link) (PDF)

      • From a product standpoint, Twilio’s acquisition of SendGrid will likely be successful. 

      • While market valuations are currently stretched and office locations differ for Twilio and SendGrid, the combination of Twilio and SendGrid will create a strongly compelling suite of communication products at Fortune 500 scale. Twilio’s product portfolio is largely focused on telecommunications (Phone Call and Text Messaging APIs) while SendGrid is primarily email based, with limited product portfolio overlap, upsell/cross sell opportunities will likely be fairly strong. 

      • Twilio’s expertise is also likely in building telecommunication related infrastructure, not email sending infrastructure, so the overlap in expertise is likely minimal and a significant positive to an acquisition instead of building that solution in house. 

      • Twilio has its own in house Corporate Development team, and having recently gone public, understands the process of buying and selling equity. 

      • Twilio’s team is also betting that the future of customer communication is multi-channel/multi-medium, which I would agree with at this point. 

      • Assuming cultural differences are not significant, this will likely be a strong acquisition over time for Twilio. 

    • Bad Example - SAP’s Purchase of Qualtrics for $8B (Link) (PDF)

      • SAP is one of the largest software companies in the world, possessing significant technical and financial resources. Both of which make this acquisition puzzling.

      • While Qualtrics is a solid piece of survey software, it is by no means uniquely adept, and building survey software does not require specific domain expertise that is difficult to obtain elsewhere (Unlike Autonomous Vehicles for example). SurveyMonkey is even a public company with greater revenue than Qualtrics, and could have been purchased for a significantly lower valuation. 

      • SAP’s customer base is also orders of magnitude larger in both revenue and customers, so bidirectional upsell opportunities will likely be limited. 

      • From public comments, the justification appears to be that SAP will be able to sell Qualtrics software across their entire portfolio. I would question whether the easiest way of achieving that goal was to spend $8B to acquire a solution or to simply have partnered with Qualtrics / create a joint venture / build a solution internally. 

      • This appears to be a case in which SAP has far too much cash and feels as though a better way of spending that cash is on acquisitions versus reinvesting. 

      • A fantastic result for Qualtrics, likely a poor long term result for SAP from a ROI perspective given the price paid. 

  • Building Solutions

    • Good Example - Products Reliant on Customer Data Sets

      • A good example of a product that is better built internally is any product that relies on your own customer data sets. 

      • While possible, it is always more difficult than it needs to be to sign confidentiality agreements that make sense and built the infrastructure necessary with a partner to be able to build a product on top of those data sets. 

      • These types of products are also likely to require constant tweaking to properly address the business problem, which is made more difficult if done through a partner. 

    • Bad Example - Payments Technology

      • One instance in which it likely doesn’t pay to roll your own system is payment processing. 

      • Unless you are operating at a scale where the cost of rolling your own is trivial, building a payment process solution that is continuously updated, secure, and performant is a task better left to payment processors who are dedicated to providing those solutions. 

      • There is little competitive expertise your team would gain by building it in house, payment processing is a fairly standard and commoditized industry (Stripe, PayPal, etc.), and partnering or outsourcing this responsibility frees your team from significant liability associated with credit card processing. 

      • As a general rule, components that are heavily regulated while also being broadly commoditized are products that are better outsourced.

  • Partnering to Obtain Solutions

    • Good Examples 

      • Just like good acquisitions, good partnerships are in complementary spaces, with bidirectional upsell/cross sell opportunities, and are additive to each company.

      • Airlines & In Flight Internet Providers

        • While airlines are not technology companies capable of rolling their own in flight WiFi systems, and in flight WiFi system companies are ill equipped to run an airline, a partnership between GoGo wireless and American Airlines allows both companies to create revenue and provide a service where neither company could succeed working in isolation. 

      • McDonalds & Uber (Link 1) (PDF 1), (Link 2) (PDF 2)

        • A good example of a partnership involving network effects is McDonald’s choice of partnering with Uber for food delivery. It would be virtually impossible for McDonalds to cost effectively build a delivery network as pervasive as Uber has already built, and a partnership with Uber allows McDonalds to capitalize on Uber’s hard earned network effects to determine if delivery is a sales channel it wants to pursue for the long term. 

    • Bad Example

      • Content Providers & Netflix

        • One key to partnerships is understanding where your organization and your partner’s organization fit in to your company’s overall go to market strategy. A mistake in judgement can allow partnerships that are actually harmful to your company’s well being to appear to be initially successful. 

        • One example of this is content providers early partnerships with Netflix. Superficially, content providers viewed Netflix as a new method of distribution for their content (Just like home video, cable, Video On Demand, airplanes, and movie theaters) and felt that licensing their content could bring in a new stream of high margin revenue. 

        • While it was additive from a revenue perspective, content providers made the mistake of believing Netflix was only a new method of distribution, instead of a full blown competitor in content creation and as owning not just the distribution method, but the customer relationship as well. 

        • These are the primary reasons major content producers are now pulling their content from Netflix and creating their own streaming services. 

        • In this case, the content provider’s critical error was assuming that Netflix was simply a new distribution channel, when in reality it was entirely new competitor. 

N Order Consequence Modeling with Autonomous Vehicles

Summary

  • N Order Thinking is simply the ability to think beyond the superficial and consider not just an initial action and potential results, but the actions/potential results N Orders after your initial action/result pair.

  • N Order Thinking is important in product management because it allows a deeper understanding of the potential problem/solution space that can be interacted with and that you as a product manager must understand in order to reach a global maximum, not just a local maximum.

  • In my experience, N Order Thinking is present to varying degrees based on PM skill levels. N Order Thinking is an incredible differentiator in more junior product managers.

  • The below charts for both PM Skill Level and N Order Thinking with Autonomous Vehicles can also be downloaded as the original XLS here.

Detailed Discussion

  • What is N Order Thinking?

    • N Order Thinking is often explained in the context of Second Order or Third Order decision making. While that is useful when introducing the concept, as it is initially difficult to think more than 2 or 3 layers deep, this post is designed to broaden the concept so as to encourage product teams continue beyond the 2 or 3 derivatives this concept typically encapsulates. Hence the term “N” Order Thinking. 

    • At its simplest, an order of thinking is defined as a layer of observation, question, or statement.

    • Example of 1st Order

      •  Social media advertising is effective and efficient because that is where our demographics spend their time.

    • Example of 2nd Order

      • Why is social media advertising effective/efficient just because that is where our demographics spend their time? Is that also where/how they plan to purchase our good?

      • Social media advertising is effective and efficient because that is where our demographics are most receptive to our advertising and digital creative because we are a digital first brand targeting Gen X in coastal cities.

    • The differentiating factor between 1st and 2nd order thinking is going one layer deeper than is typical with three key questions:

      • Is the reality that has been presented in the initial statement broadly true (generalizable) or only in specific scenarios (not generalizable)?

      • Is the observation properly addressing correlation and causation issues?

        • Aside – This is staggeringly overrepresented in product related decisions unfortunately.

      • Is the question attempting to identify the root cause of a certain result or simply the one most readily and easily identifiable?

    • These three questions can be extended all the way down to N orders of thinking until the product manager feels that they have reached a point at which action can be taken.

  • Why is N Order Thinking important and relevant for product teams?

    • N Order Thinking is a necessity for continued and sustainable product innovation as it requires the thinker to identify root causes or customer problems that will move the needle, not just those that are easy to solve or will check off a KPI on number of JIRA tickets resolved that week.

    • It is also a useful tool in working through complex scenarios in which there are a multitude of stakeholders, potential customers, barriers to entry, and strategies for success. Not unlike a decision tree, N Order Thinking attempts to ferret out the most fundamental attributes of what on first approach seem to be intractably large problem spaces.

    • If your team, or at the very least your product leadership team, does not employ N Order Thinking it will be difficult to maintain product leadership in your category over time because you will remain focused on solving problems your customers know they have, not the ones they don’t realize could be solved. Solving problems customers don’t realize they have is the essence of disruption.

  • What is the cost of N Order Thinking? When should it be deployed? How can product teams utilize the concept?

    • N Order Thinking is useful, but shouldn’t be deployed in every scenario or by every product team member due to the time that it takes to think through each question to the Nth degree.

    • It should most often be deployed when entering new markets or creating new products to identify potential problem/solution pairs that may have been overlooked in initial product requirement documents.

    • It can also be deployed for products that have stagnated in their market and the product team is attempting to understand whether that product should be deprecated or can be applied to a new use case.

  • How can product teams learn to be better N Order Thinkers?

    • N Order Thinking is difficult and takes significant effort to understand and incorporate into the way in which your products are built.

    • Before going 10 layers deep in a brand new product, attempt the exercise in an existing product or feature that is stagnating and where the problem sample space is relatively narrow.

    • It can also be helpful to utilize diagrams, such as the Excel file example of Autonomous Vehicles at the beginning of this post, but which can be as simple as a decision tree drawn on a whiteboard.

Examples

Let’s apply N Order Thinking to what is currently an entirely open ended market: autonomous vehicles. While applying N Order Thinking is typically faster than in this example because your sample space will be constrained by your product, you will also encounter scenarios, similar to the one below, in which you are developing a new product or service with a wide-open set of possibilities. These are necessarily more complicated, and N Order Thinking helps to explore, document, and understand those possibilities.

 The following discussion will walk through one branch of the flowchart embedded below, which can also be found in the Excel file linked at the top. This diagram is by no means complete, but is designed to demonstrate how quickly and extensively N Order Thinking can explore new products and business lines.

  • On “zero” glance, or zero order, one might state that autonomous vehicles will change the way we drive and transport goods because there will no longer be a human driver.

    • This is true, but it doesn’t tell us why it will change the way we drive/transport other than the obvious implication that a human will no longer be driving those vehicles.

  • Moving to first order, we might state that there will two types of vehicles that full vehicle autonomy can be applied to: cars and trucks.

    • This is also true, but it doesn’t tell us how those autonomous vehicles will interact with their now non-drivers or the service providers that previously supported non-autonomous vehicles.

    • This is of course not comprehensive of the vehicle types that autonomous technology could be applied to, but is a good example of how to reduce the scope of an N Order analysis.

  • Moving to second order, examining just the car branch, we might now state that autonomous cars will impact the world in two ways: trip types and vehicle service providers.

    • Again, true, but have we delineated those trip types or what kind of support vehicle service providers currently provide and how those might be altered with autonomous vehicles?

  • Moving to third order, examining just the Trip Types, we might now state there are two trip types, personal and commercial.

    • Yet again, a true statement, but we haven’t yet answered one of the three questions above, which is whether we have identified the root cause / problem / potential business.

  • Moving to fourth order, examining just the Commercial Trips, we can identify that there are potentially three stakeholder groups impacted: Deliveries, Emergency Services, and Education.

    • We are getting closer as we are starting to identify individual business segments, but we aren’t yet at a level of specificity where we can identify problems to solve because we haven’t identified potential stakeholders.

  • Moving to fifth order, examining just the Deliveries branch, we can identify a specific enough industry that we can start asking intelligent questions.

    • In this case, if we look at delivering Mail, we can start to ask whether those types of Car -> Trip Type -> Commercial Trips -> Deliveries -> Mail will make sense if the underlying vehicle will be autonomous.

    • Getting to this level allows us to see the entire picture in which those decisions will be made (the other segments such as Food and Packages – E-Commerce) and whether those segments might be more appealing because they have higher/lower barriers to entry, lower / higher CLTVs, more / fewer competitors, etc.

    • In other words, your product team is unlikely to do well building a product that caters to solving the problems of a 4th order segment and all of its corresponding branches (IE – Deliveries -> Food & Packages – E-Commerce & Mail) because the use cases will be so different.

  • N Order thinking allows a bottom up approach to identifying potential business segments and their potential problems that can be turned into business / product lines.

 

Closing Commentary

  • As a product team, your highest priority should be on identifying the highest ROI problem/solution pairs in markets you currently address or could feasibly address.

  • N Order Thinking allows you to model those possibilities in a more quantitative way and hopefully address the three questions that can reduce product team decision quality explored in the Detailed Discussion section above.

  • The next step after getting to what you believe is the final order of thinking for your particular problem is asking the best questions possible, some of which will lead to their own N Order exercise, but will hopefully begin to provide metrics around the business problem with which your team started.