David Cummings on Startups

Category: Product Mgmt

  • 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?

  • 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 prospectinsight.com 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?

  • Platforms and Microservices

    Steve Yegge has an epic rant on Amazon being a poor place to work but more brilliant than Google when it comes to innovation at platform scale from 2011. David Skok recently published a post on his blog titled Microservices Essentials for Executives: The Key to High Velocity Software Development. The idea is that tech companies start out building their product as one large, monolithic system because it’s simpler and faster. Then, as the startup achieves greater levels of success, innovation slows down considerably even though more and more people are added to the product team. What gives?

    The larger the product, the harder it is to make changes to it due to all the dependencies. Amazon was the first major technology company to realize that Internet scale, and it’s greater levels of complexity, requires a new way of building large-scale systems: microservices. Microservices are simply smaller, self-sufficient special purpose products that form a platform (e.g. tiny apps that are used to make a big app). Amazon went further and built Amazon Web Services (AWS) to make the backend of these microservices even easier to manage and scale, and now AWS is one of the fastest products to $10 billion in annual revenue, ever.

    Tech entrepreneurs need to understand the benefits of microservices and start planning them once they hit the growth stage, but not before. All major platforms going forward are going to have some form of microservices underpinning them.

    What else? What are some more thoughts on platforms and microservices?