Challenges of First Starting a Product

Today we kicked off our first investment for Shotput Ventures 2010. Now, like Shotput last year, we don’t talk about the specifics of our portfolio companies until they launch, but one of the things I want to do is capture more of the lessons learned as we go through the 12 week mentoring process.

During our discussions about their product today, which comprised most of the few hours, several issues were brought up:

  • What’s the right balance between working on code and talking to prospects?
  • How simple should a minimum viable product actually be?
  • What functionality can standalone and what is dependent on other items?
  • How should the features be prioritized?

While there is no right or wrong answer, one piece we did quickly realize is that the team was building a good bit of functionality that was overkill for getting something out the door that added real business value. This is especially true when there’s such a clean slate with a new product — new features are incredibly easy and fast to add. The hidden problem, which most entrepreneurs don’t appreciate until after they’ve felt the pain, is that these quick-to-add features add code debt and actually slow down development in the future — when it is even more important to move fast.

My advice: ask yourself “Do we really need this?” for every little feature or option of a feature when building a product — you’ll appreciate it in the long run.

One thought on “Challenges of First Starting a Product

  1. Good post. I agree it’s a huge challenge to determine the minimum viable product. It’s so easy to get caught up in “add more features mania”.

    Suggested approach: take a step back and consider product as a solution that _simplifies_ instead of a solution that _modernizes_. Building a modern product invites tons of features; building a product that simplifies can, well, simplify the design/development process.

    One solution to wasting time building features that no one wants is to take customer-centric approach by asking clients: “Would you pay for feature X?” If so, add in the feature when/if customer does in fact pay. Test hypotheses, and then iterate.

    Check out Steve Blank’s blog for more on this approach. E.g.,

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.