You Can Never Over Invest in Product

One of the phrases I’ve heard a couple times in the past week is “you can never over invest in product.” The idea is that once you have product/market fit and a repeatable customer acquisition model, sales and marketing is always out in front of product development. There’s a natural tension between the go to market teams and the product/engineering teams, but often there’s an imbalance. Product development and engineering have nearly infinite economies of scale when combined with a great market.

Here are a few reasons why you can never over invest in product:

  • Finding great software engineers, UI/UX professionals, and product managers is really hard. No matter how fast you’d like to hire, it always takes longer than expected.
  • Software products have almost no marginal cost and great economies of scale making each incremental prospect signed and customer renewed that much more valuable. Better products make for happier customers.
  • Market opportunities come and go. If there’s a really special opportunity at hand, the opportunity cost of not winning the market is enormous.

Once entrepreneurs are in the growth stage of the business, you can never over invest in product. An amazing product has so many benefits, and opportunities.

What else? What are some more thoughts on the idea that you can never over invest in product?

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?

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?