David Cummings on Startups

Category: Product Mgmt

  • Post Mortem on a Failed Product

    Just over two years ago, at the beginning of 2008, we set out to build a web content management system with community functionality infused throughout — eCrowds. The idea was that companies would need a solution for facilitating product communities with the following functionality:

    • Content management
    • Forums
    • Blogs
    • Idea exchanges
    • Wikis

    We were solving the traditional challenges brought on by disparate silos of data with separate user authentication systems and inconsistent interfaces/template designs. 2008 was spent building the product and we launched it for our own internal customer success communities after nine months of development. It was a failure.

    Here are some of our lessons learned:

    • We spent way to much time building it for ourselves and not getting feedback from prospects — it’s easy to get tunnel vision. I’d recommend not going more than two or three months from the initial start to getting in the hands of prospects that are truly objective.
    • We made the product much too broad such that it did a little bit of everything. Unfortunately, it didn’t do anything exceptionally well. As an example, when we used it to replace our phpBB message board instance, our community was in an uproar because it lacked many of specialized features a mature forum offers (e.g. notifications and handling code examples in a comment).
    • The tools we were replacing were pretty cheap (e.g. each item was typically under $100/month), and we wanted to focus on the small-to-medium sized business, as that was our area of expertise, so we priced the product around $500 – $1,000/month. This caused another major disconnect — the integration costs were typically $10,000 to migrate an existing site into the system. With those integration costs, the sales cycle became prohibitively long/expensive relative to the lifetime value of the customer and the recurring revenue.
    • As the product became more and more complex, the performance degraded. In my mind, speed is a feature for all web apps so this was unacceptable, especially since it was used to run live, public websites. We spent hundreds of hours trying to speed of the app with little success. This taught me that we needed to having benchmarking tools incorporated into the development cycle from the beginning due to the nature of our product.

    So, to summarize, I recommend getting something simple into the hands of prospects quickly, picking out a narrow niche and doing it well before going broad, thinking through the economies of customer acquisition costs relative to the revenue generated, and making sure the app always runs fast.

    What else? What are some other lessons you’ve learned from a failed product?

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

  • The Perfect Product Challenge

    One of the major challenges with a web application is the allure of making it perfect. Who doesn’t want the perfect product? Perfect is the enemy of good. A good product gets out the door and is put in the hands of prospects. A perfect product doesn’t exist, and while it is being built, time, energy, and especially money is being consumed.

    My recommendation is to get the product into the hands of prospects as quickly as possible. And when I say prospects, I’m thinking about random ones, not just warm intros. Warm intros are definitely worthwhile and should be used, but also make things too easy that an objective buyer might not provide.

    I’ve seen too many startups never fully get a product out the door. Don’t join the crowd! Launch early and often.

  • User’s Conference Planning

    We’re deep into the process of planing our annual user’s conference. I really underestimated the power and importance of user’s conferences before we put on our first one a few years ago. There’s something incredibly powerful about spending a day or two with customers, learning how different clients use your product, and talking about the future vision. It really is a great morale builder and helps nurture and deepen relationships.

    Here are a few general items we think about as part of our user’s conference planning:

    • Charge a reasonable fee that barely covers costs but still allows for a great event
    • The venue is extremely important and should be recently renovated and professional (don’t skimp on the venue!)
    • Have as many clients speak as possible — customers love to learn from other customers
    • Provide a back channel for clients to communicate including a Twitter hashtag
    • Line up the conference dates at least six months in advance and solicit speakers for the agenda
    • Get partners/resellers involved in addition to customers and employees
    • Include a happy hour or field trip to help foster relationships
    • Buy the best internet access you can afford and get backup options like 4G wireless
    • Make it fun!

    What else? Have you been to a user’s conference that was especially memorable?

  • Product Community Tools

    Continuing with the topic from yesterday on Tools for Product Communities, let’s look at some example products from the different categories:

    Please let me know what other tools you like and recommend.

  • Tools for Product Communities

    One of the challenges for a growing company is to put processes and procedures in place to systematize how the organization operates. The idea is to add some level of reproducibility of what goes on so as to be able to scale to a company size that is many times larger. An area that is especially ripe for putting in tools to generate better economies of scale is that of online product communities. Here are some tools to consider:

    • Knowledge base / articles
    • Frequently asked questions
    • Message board / forum
    • Idea exchange
    • Blog

    I recommend starting with one or two of these types of tools at first and eventually incorporate all of them to engage the product community.

  • Build a Web App on a Budget

    I had lunch with an entrepreneur today and we talked about the web app he’s building. He was interested in my thoughts on how to do it in a scrappy, but high quality manner. I told him to use these sites and services:

    As for the programming of the web app, I recommend hiring a good software engineer in-house, but that’s a much longer topic. Good luck!

  • Roadmap Buy-in Process

    We’re in the midst of our product roadmap planning process right now in order to line up our desired releases for 2010. At first, we thought about bringing in the managers of different departments together to lobby for changes they’d like to see. After evaluating that strategy, we decided to do a hybrid of some managers and some key stakeholders that were passionate about specific areas of the application.

    The fun begins when everyone holes up in a room for several hours hashing everything out. My advice for product managers is as follows:

    • Solicit input from as many different people and types of constituents possible
    • Acknowledge that you can’t do all things for all people but will strive for improvements that 80% of users can benefit from
    • Attempt to incorporate at least one request from each group of users, even if it is a small one, so that you can show them their input matters
    • Always over communicate everything in a variety of mediums (email, phone, in-person, blogs, newsletters, etc)

    Product roadmaps are challenging, and have a short shelf-life, but are an important part of technology companies.

  • Web App Mockups / Wireframes

    For product managers and entrepreneurs, one of the more challenging tasks is to efficiently get the product interface and user experience ideas into the hands of a web designer or software engineer. Thankfully, there’s been a nice group of competing products recently that address this issue with web-based, easy-to-use applications just for doing mockups / wireframes. Here are some of the more prominent ones:

    I’d recommend anyone who’s involved in developing software and web applications take a look at this new genre of tools.

  • User Feedback

    One of the most profound changes the Internet has brought to the world of software companies, besides software-as-a-service, is that of user feedback. When I say user feedback, I don’t mean just getting emails with feedback on the product, rather I mean all the different ways people talk about the product with you, with others, and on their own. Think about some of the common ways people provide feedback now:

    • Email
    • Phone
    • Twitter
    • Facebook
    • Message boards
    • Idea exchanges
    • Blogs

    The list goes on and on. Generally, the key isn’t to try and be all things to all people. My favorite strategy is to keep track of feedback in a structured fashion (e.g. inside a CRM or Google Spreadsheet) and then once a change has been made that addresses one of those ideas, reach out to the person or all the people that submitted it, and tell them we listened to their request and made the change in the product. You’ve just won a customer for life.