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?

Agile vs. Burndown Software Development

Matt Bilotti has a great post titled How We Build Products at Drift. The crux of the article is that there’s a new, and better, way to do software development: burndown. Today, in the startup world, agile is the most common software development methodology. Only, it’s centered around the two week sprint, and the reality is that the customer feedback loop is much faster than two weeks.

Here’s the breakdown on agile vs. burndown from the post:

  • Measure of success
    • Agile – Thoroughness of story, agile points and velocity
    • Burndown – End user feature adoption & retention
  • Means of determining prioritization
    • Agile – Product backlogs and sprint planning
    • Burndown – End user validated design mockups and prototypes.
  • Speed
    • Agile – Story-based sprints (weeks)
    • Burndown – Micro-sprints (days)
  • Release focus
    • Agile – Multiple features grouped into a single release version
    • Burndown – A single version of a single feature per release
  • Flexibility
    • Agile – 2-week sprints are planned, executed & generally inflexible once agreed upon
    • Burndown – Every day priorities change and so do the current and upcoming sprints

Feel like the agile software development methodology isn’t quite right for your team? Consider trying out some of these burndown concepts.

What else? What are some more thoughts on agile vs. burndown methodologies?

Simple Product Management Planning Process

Scaling the product management planning process is a real challenge as the startup goes from idea stage to early stage to growth stage. At first, the entrepreneur guides all product functions. Then, there are too many different pieces and a product management group convenes on a regular basis to plan and curate functionality. Finally, product management becomes it’s own team (initially a team of one) and grows from there. Naturally, more process is required as the company grows.

Here’s an example product management planning process:

  • Create a simple Google Spreadsheet with sheets for different constituencies
  • Solicit requests from sales, marketing, services, support, client advocates, product management, and engineering in individual sheets
  • Review the customer idea exchange and take the top 10 most popular items and 20 other items that have the most bang-for-the-buck and add them to a new sheet
  • Analyze trends from the 100 most recent support tickets and confirm the big ones are in the Google Spreadsheet
  • Categorize every item based on priority (low, medium, high) and difficulty (low, medium, high)
  • Get a group of stakeholders together, no more than five people, and debate everything that’s been assembled and decide on the items for the next quarter
  • Share the quarterly roadmap with the team and ensure alignment
  • Repeat each quarter

Start with a simple product management process and expand it from there always considering the balance between moving fast and making the best decisions possible.

What else? What are some more thoughts on a simple product management planning process?

No Product Roadmaps

Continuing with yesterday’s post on Quarterly Product Themes, another area we struggled with at Pardot was product roadmaps. Early on, we tried to map things out for the product. We’d come up with an idea to do Z, and in order to Z we first needed Y, and everything was laid out beautifully. Then, a week later, this other idea/request would come up, we’d debate it vigorously and decide it was more important than an item on the roadmap. Staying close to the customer required a short feedback loop and necessitated rapid product iteration.

It was time for a change. It was time for no product roadmaps.

Instead, we had a Google Sheet with a separate tab for each department in the company and their product requests along with a GetSatisfaction idea board for customer requests. Finally, there was a Google Sheet tab for the priority product items and that constantly changed as we moved requests in and out as well as implemented new features and fixes. When a prospect or customer would ask about our product roadmap, we’d say we don’t have a detailed roadmap due to the need to stay nimble, but we’d share big broad ideas about our general strategy and product direction. The product roadmap was no more.

What else? What are some more thoughts on not doing product roadmaps?

Quarterly Product Themes

One of the challenges we had at Pardot was balancing the different requests from our constituents. Sales wanted one set of features while customer success wanted a different set of features. Then, support had their own desires separate from engineering which wanted to make a number of behind-the-scenes improvements. What to do?

We eventually arrived at doing a product theme every quarter where we alternated between heavy market-facing improvements (lots of shiny bells and whistles for sales) and heavy back-end improvements (lots of infrastructure work, fixing of nagging issues, and general product polishing). This process worked well in that it was clear to our different stakeholders where the emphasis was for the quarter, along with the expectation of what we’d do the following quarter.

Consider using product themes for each quarter as the startup grows and product demands increase.

What else? What are some more thoughts on quarterly product themes?

Make Company Name and Product Name the Same

At Pardot, we originally named our product Prospect Insight, thinking we were cool with a product that was abbreviated PI (Note: You can still go to and it redirects to Pardot). Only, at the time, we didn’t understand that it was a bad idea to have a product name separate from the company name. As we started to gain traction, customers would refer to the product as Pardot, and not Prospect Insight. Eventually, we realized that to our customers the product was one and the same as the company, and we dropped the product name Prospect Insight.

The company name and product name should be the same. It’s hard enough to build one new brand, let alone two simultaneously. Make things easy and simple: keep the names the same.

What else? What are some more thoughts on making the company name and product name the same?

Going Deep or Broad with the Product

One of the product questions entrepreneurs need to ask themselves early on is if they’re going to go deep or broad with the application. In general, as customers ask for new features, they have a tendency to be broader requests (e.g. can you add adjacent feature XYZ?). Keep in mind the importance of product focus, especially the part about being opinionated.

Here are a few questions to ask when considering going deep or broad:

  • Is this product a point solution or a platform (everyone wants to be a platform but point solutions are much more common)?
  • Does this feature request strengthen an existing feature or does it introduce a new concept?
  • Are customers asking for more product depth or more product breadth, generally?
  • Does the product roadmap reflect more depth or breadth? Is that direction intentional?
  • How does depth and breadth reflect reflect the current customer base vs the desired customer base (e.g. entrepreneurs often want to expand upmarket over time)?

Entrepreneurs would do well to think through their product strategy when it comes to going deep or broad with the application. Deep is the more common successful route.

What else? What are some more thoughts on going deep or broad with the product?