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?

Today’s Business Ideas That Weren’t Possible 10 Years Ago

One of the ways I like to think about business ideas is in the context of what can we do today that we couldn’t have done 10 years ago. As an example, when we started Pardot in early 2007, we could build a web application quickly using open source software, run it on commodity web hosting, and deliver B2B marketing automation with analytics, campaign execution, and insights in a cost effective manner to SMB customers. 10 years prior it would have been 100x more to build it, 100x more to host it, and the market wasn’t ready for it (being too earlier is still a failure).

Here are a few things to think about when considering ideas that weren’t possible 10 years ago:

  • What new ideas are possible because we have a super computer in our pocket (e.g. iPhones didn’t even exist 10 years ago)?
  • How can we use cloud computing and big data tools like Hadoop to unlock insights we never knew about before?
  • How do advances in technology in one industry help another one (e.g. GPU advancements helping self-driving cars, cell phone miniaturization helping a number of other devices, etc.)?
  • What ideas were good before but the timing wasn’t right (e.g. limited broadband penetration, GPS adoption, independent contractor availability, etc.)?

The next time you’re considering a business idea, ask the question why wasn’t this done 10 years ago and see what you come up with. Some ideas weren’t even possible and some ideas were just before their time.

What else? What are some more thoughts on thinking about business ideas in the context of what wasn’t possible 10 years ago?

The Most Successful B2B Apps are Must-Haves

One area I see a number of entrepreneurs struggle with is building a product that is truly a must-have for their customer. While it’s true that every spreadsheet is another SaaS app, the reality is that if what the app does is only slightly better than the spreadsheet, it’s going to be a nice-to-have and not a must-have. Why? Because spreadsheets are commonplace, well understood, and people don’t like change. The most successful B2B apps are must-haves.

Here are a few ideas for assessing if an app is a must-have:

  • Customers say things like “I don’t know how I did my job before XYZ” and “I can’t run my business without XYZ”
  • If the app goes down, customers are calling immediately (as opposed to shrugging their shoulders and not caring)
  • Customers use the app multiple times per week, if not daily, to accomplish something important
  • Is the app clearly in the path of revenue?
  • The results (value delivered) are not possible without specialized software (e.g. the data isn’t available without the system capturing it, the data size is too large to process it in spreadsheets, the data is too siloed, the data is too large to be actionable without automations, etc.)

Building a B2B app is easy. Building a must-have B2B app that hundreds or thousands of customers use is incredibly hard. Build a must-have B2B app whenever possible.

What else? What are some more thoughts on the idea that the most successful B2B apps are must-haves?