Most Second Product Initiatives Fail

Recently I was talking with some entrepreneurs and the topic of second products came up. Here, a second product would be an additional product offering that’s a true, standalone product and not an add-on to the original product. Without missing a beat, everyone went around and said that every second product they launched failed.

I’ve been there. I’ve tried launching a second product multiple times and they all failed. Why?

Here are a few thoughts:

  • Lack of Product/Market Fit – Inevitably, a new product doesn’t accurately meet the needs of the customers. Even with one product that does have product/market fit, it’s incredibly hard to build a second one.
  • Must-Have vs Nice-to-Have – Very few products are a must-have. The chances are high that while the first product was a must-have, the second product was a nice-to-have.
  • Best People Challenge – With one product working, the likelihood that the very best people are assigned to a new product is low. And, if they are assigned to the new product and the first product starts to have issues, they’ll be pulled back to the first product immediately.

Second products can work but entrepreneurs would do well to maximize every element of their core product before expanding.

What else? What are some other reasons why second product initiatives fail?

Jobs to be Done Framework

Clayton Christensen, author of the The Innovator’s Dilemma, also invented the “Jobs to be Done” framework.

From the Clayton Christensen Institute:

The jobs-to-be-done framework is a tool for evaluating the circumstances that arise in customers’ lives. Customers rarely make buying decisions around what the “average” customer in their category may do—but they often buy things because they find themselves with a problem they would like to solve. With an understanding of the “job” for which customers find themselves “hiring” a product or service, companies can more accurately develop and market products well-tailored to what customers are already trying to do.

Too often, entrepreneurs think in terms of features. If our product does X,Y, and Z, then people will buy it. Instead, think about the job that needs to be performed and how the solution will fit it. Think solutions to jobs, not features.

What else? What are some more thoughts on the jobs-to-be-done framework?

Product-First or Movement-First Startup

When I reflect on four of the fastest-growing ~100 person startups in town, it’s clear that they fall into one of two camps: product-first company or movement-first company.

Product-first companies absolutely adore their own product. Everything centers around building an amazing product that customers love and everything else comes second. Internally, software engineers and the product team are put up on a pedestal and the hierarchy is clear. Product-first companies are all about the product.

Movement-first companies are on a mission greater than themselves. Everything centers around educating the market about this better way to do things, most often through live events and heavy sales and marketing. Internally, sales and marketing teams are hard-charging and at the center of the company. Movement-first companies are all about creating a movement.

What’s the better route? Both are great ways to do it and have their own pros and cons, and both produce very successful businesses. Startups that aren’t amazing at one or the other often fail. Pick one thing and do it well.

What else? What are some more thoughts about product-first and movement-first startups?

6 Strategy and Planning Methodologies to Explore

As an entrepreneur, I always enjoy analyzing and thinking about startups in a number of different ways. Thankfully, a number of other people do as well, and several have come up with great methodologies to help influence and inform our thinking. Here are six strategy and planning methodologies to explore:

  1. Simplified One Page Strategic Plan
  2. MSPOT – Mission, Strategy, Projects, Omissions, and Tracking
  3. V2MOM – Vision, Values, Methods, Obstacles, Metrics
  4. Business Architecture Stack
  5. Business Model Canvas
  6. Startup Positioning Template

The goal here isn’t to implement every methodology. Rather, experiment with them and see which one resonates most, and use it on a regular basis to help with strategy and planning.

What else? What are some more strategy and planning methodologies you like?

A Feature vs a Product

Whenever an entrepreneur shares their idea with me, the following question always comes up, “is this a feature or a product?” Occasionally, it’s clear that this is a feature with product and platform potential, but most products, especially minimum viable products, start out as a feature solving a simple problem.

At Pardot, version one of our software tracked individual page views of prospects (micro web analytics) and captured web forms. Over time, email marketing, landing pages, scoring, grading, automation rules, drip programs, and more were added. At first it was a feature and then over the course of several years became a product.

Here are a few questions on the feature vs product debate:

  • How valuable is this functionality as a standalone application?
  • How much more valuable is this feature as part of a broader set of features?
  • How much of a nice-to-have vs a must-have is this functionality?
  • Are there existing products in the market that should add this feature? Why or why wouldn’t they do that?
  • Where is the market headed? More standalone features or products that combine features?

The feature vs product debate is ongoing, but one of the main takeaways is whether or not an ecosystem and industry gets built around the business (a product/platform) or if the business runs in more of a silo and offers a more limited, but highly focused, feature.

What else? What are some other thoughts on the idea of a feature vs a product?

Scenario Planning

One of the fun things to do with spreadsheets is build out different “what if” scenarios around sales, marketing, operations, fundraising, exit opportunities, and more. So many different inputs, data points, metrics, and formulas to test. Only, to do this efficiently and effectively, it’s imperative to have accurate data and tools.

Here are a few thoughts on scenario planning:

  • Ask an advisor, mentor, board member, or fellow entrepreneur for an existing spreadsheet to use as an example
  • Resist the temptation to just plug in a number (e.g. 2% of calls will result in a demo), and instead use real data from the current team in the current time frame (e.g. use a system like SalesLoft to capture the outbound call, email, and demos scheduled data)
  • Build multiple scenarios for each “what if”, including the high/medium/low outcomes or optimistic/average/conservative outcomes
  • Run the results by an experienced CFO or entrepreneur and solicit feedback
  • Shares the results with key members of the team and use it to inform decision making

Scenario planning is a common strategy entrepreneurs use to grow their business. Build out different “what if” scenarios and make better decisions.

What else? What are some more thoughts on scenario planning?

The Three Main Functional Categories for B2B SaaS Apps

When analyzing B2B SaaS opportunities, I like to think through things like nice-to-have vs must-have, market size, point on the lifecycle adoption curve, etc. There’s another area that I like to bucket SaaS apps: functional categories. Functional categories are a big, general way to think about what the app does and how it fits in with the user.

Here are the three main functional categories for B2B SaaS apps:

  • Major Job Function (Workflow) – This is for apps where the app is one of the top three apps used daily by the person (e.g. SalesLoft and Gmail would be the main apps for an SDR).
  • Specialized Job Function – This is for apps where the app is used at least weekly to accomplish a function but aren’t an app that the end user “lives” in daily (e.g. Calendly for automating meeting scheduling).
  • Utility – This is for apps that are always running in the background acting as a utility for a specific function (e.g. Rigor for performance monitoring).

Look at the public SaaS companies and you’ll be able to easily categorize each one into one of the three main functional categories for SaaS apps. Also of note is that the largest SaaS companies by revenue are all major job function apps (there are plenty of successful specialized job function and utility apps as well, but they aren’t nearly as large as the major job function apps).

What else? What are some more thoughts on the three main functional SaaS app categories?