David Cummings on Startups

Category: Product Mgmt

  • Initial Customers Always Find Bugs

    Signing the first few customers is incredibly difficult (see The First Five Customers), yet after all that effort, the next challenge is keeping them as they inevitably find product bugs. No matter how extensively you test the software, end users always come up with edge cases and scenarios that you never dreamed of trying.

    Here are a few thoughts to keep in mind with initial customers and bugs:

    • Product bugs are normal and it’s best to budget development time in advance for fixing them
    • Apologize whenever a customer finds a bug and set expectations that it will be fixed quickly
    • Find a balance between automated testing (unit, integration, etc) and human testing
    • As the product matures, new customers will stop finding as many bugs

    Product bugs are commonplace. With customers it’s critical to communicate and get things fixed quickly, especially for the early adopters. Over time things will settle down and the product will become more stable.

    What else? What are some other thoughts on initial customers always finding bugs?

  • Atlanta Tech Village Accelerates Early User Acquisition

    Yesterday I was walking through the Atlanta Tech Village introducing an entrepreneur to other entrepreneurs that could use his cloud-based product. As an entrepreneur, one of the most challenging and time consuming tasks is getting companies to actually use and provide feedback on a new product. Yes, with customer discovery companies should be engaged before building the product but often times more companies are needed to evaluate the product once it’s under construction.

    Enter a community of like-minded entrepreneurs.

    Actively paying it forward and helping each other out by using a new product and making introductions to potential users, there’s an accelerated timeline to achieving product/market fit (stage 1). And, all too often, it’s an accelerated process to realize that there’s not enough pain or demand in the market, so it’s time to pivot and go a new direction.

    The next time users and introductions are needed, consider getting involved in a community to help accelerate the process.

    What else? What are some other thoughts on entrepreneurial communities to help with early user acquisition?

  • Assembling a Minimum Viable Product for Market Validation

    After repeatedly talking about customer acquisition, and the idea that startups are no longer required to build an amazing product upfront, the natural next question is how to assemble a minimum viable product to validate the market. Ideally, it’s getting something into the hands of prospects and figuring out the value and potential scalability of the business as quickly as possible. The days of needing hundreds of thousands of dollars to build a software prototype are done.

    Here are a few ideas on assembling a minimum viable product for market validation:

    • Build a seemingly-functional mobile app using Fluid UI and then let potential customers click around on the app
    • Create web app wireframes and map out the most salient pieces for a software engineer (wireframes are one of my favorite ways to map software ideas before a product is built)
    • Recruit a developer to moonlight and build a prototype after hours (most developers have side projects) and be ready to pay $50 – $100/hr
    • Explore freelancers and outsourcing firms on Elance, paying special attention to references that you can contact and verify quality
    • Incorporate tools for rapid prototyping and deployment like Ruby on Rails, Bootstrap, and Heroku

    Cost wise, expect to pay between $5,000 and $20,000 to get something built and published. While it might not be a minimum respectable product, it should be functional and suitable to put in the hands of users. Assemble a minimum viable product and search for market validation before spending too much money.

    What else? what are some other thoughts on getting a product into the hands of potential customers as quickly and affordably as possible?

  • Consulting Work to Fund Product Development

    One of the more common entrepreneur strategies is to use consulting work to generate cash to then fund product development. In fact, the most successful fast-growing software company in Atlanta, MailChimp, is actually owned by The Rocket Science Group, which for many years was a web design firm. The Rocket Science Group built MailChimp after identifying a need in the market for a simple, easy-to-use email marketing product, and now they have one of the most widely used products in the world.

    In thinking about consulting work to fund product development, here are a few things to keep in mind:

    • Consultants think in terms of time and materials, which can be limiting when trying to build a successful tech startup
    • Try to separate the consulting team from the product team so that the product team isn’t distracted and can focus 100%
    • Plan for everything to take three times as long and cost three times as much (it’s incredibly difficult to get past the first two stages of the B2B tech co lifecycle)
    • Join a community of like-minded entrepreneurs and find members with successful tech businesses (e.g. Entrepreneurs’ Organization)

    Consulting work to fund product development is difficult to pull off but very desirable when it works. Set internal expectations accordingly and settle in for a long adventure.

    What else? What are some other thoughts on consulting work to fund product development?

  • Gall’s Law and Startups

    Business of Software has a great video up by Des Traynor, co-founder of Intercom, where he talks about why Product Strategy is About Saying No. A couple minutes into the video, he cites Gall’s Law, which is critical for anyone in the startup field:

    Gall’s Law

    A complex system that works is invariably found to have evolved from a simple system that worked.

    A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system.

    People ask all the time why a big company can’t just throw a ton of money at an idea and knock-off the market leader. Gall’s Law is one of the main reasons.

    What else? What are some other thoughts on Gall’s Law and startups?

  • Custom Work to Win SaaS Deals

    As a follow-up to Balancing Desire for Full Paying Customers with the Need for Discounting, I was asked about doing custom work to win a deal. For example, statements like “I’m very interested in your product but it has to do X before I’d buy it” are common from prospects. For Software-as-a-Service (SaaS), this is even more interesting because SaaS should be a true multi-tenant architecture where everyone uses the same product.

    Here are a few thoughts on custom work to win SaaS deals:

    • Never give something without asking for something in return (e.g. sure, we’ll do 5% off our product in exchange for a case study)
    • Always debate if the custom work request is going to be applicable to 80% of the desired customers (e.g. custom work is OK if it really is going to be used by everyone else)
    • When evaluating a custom work request, get a letter of intent that the prospect will buy the product before implementing the new feature (e.g. the prospect has to show some level of commitment before engineering resources are applied)

    Custom work and product enhancements often come up in a sales cycle, regardless of product type. The key is to have a gameplan and evaluate it on a case-by-case basis.

    What else? What are some other thoughts on custom work to win SaaS deals?

  • The Cold Start Problem for Products

    Recently I was talking to an entrepreneur about his Software-as-a-Service company and he was excited that this new company didn’t suffer from the cold start problem he had previously. Not having heard this term before, I asked him to explain it to me. The cold start problem is when someone tries out a new product, like an accounting system, and there’s little real work they can do until significant integration is done (chart of accounts, import data, etc). Other products, like Rigor’s web performance management system, don’t have a cold start problem because you can turn it on and start getting value right away.

    Here are a few ideas to consider if you have a cold start problem:

    • Include high quality demo or test data so that users can experience something of meaning without doing a big integration
    • Consider having client implementation coordinators on-board new customers to ensure that clients get real value as soon as possible
    • Implement a wizard that walks the user through getting started in a way that they get small wins and have a clear picture of next steps

    Some products inherently have a cold start problem and that’s normal. Knowing that it’s a challenge, it’s best addressed in a sustainable, strategic manner.

    What else? What are your thoughts on the cold start problem for products?

  • Automatic Product Pulse With Google Spreadsheets

    Github, the largest source code hosting and collaboration platform, has a great built-in tool call Github Pulse. Github Pulse highlights key aspects of a project like number of authors, commits, pull requests, open issues, closed issues, and more in a designated time frame (e.g. 1 month). The same way Github Pulse provides an automatic dashboard of a project, startups would do well to build an automated pulse of their product usage using the Google Spreadsheets API.

    Here’s how an automatic product pulse with Google Spreadsheets would work:

    • Blank Google Spreadsheet with columns for each piece of relevant data and a new row for each day of data
    • Nightly cron job to insert a new row of data based on the previous day’s data in one or more sheets
    • Example columns: New accounts, deleted accounts, new account revenue, deleted account revenue, new users, deleted users, active users, user logins, # module A created, # module A updated, # module A used, # module B created, # module B updated, # module B used, etc (where each number represents the amount for that one 24 hour period)
    • Charts and graphs would automatically update based on data

    Overall, the idea is to spend a few engineering cycles to build a system that automatically sends data on a regular basis to a cloud-based spreadsheet so that everyone in the company can see the most important information at a moment’s notice. Taking it one step further, the product pulse could then be displayed on a large LED TV, much like a LED Scoreboard, so that the most important product metrics are always top of mind.

    What else? What are your thoughts on an automatic product pulse with Google Spreadsheets?

  • Two Products, One Startup — Don’t Do It

    Whenever I see a startup offering two different products on their website I cringe. It’s so incredibly hard to make one product successful that having a second product means resources are going to be spread more thin. Personally, I’ve tried it three times and have failed all three times. Can it be done? Yes. Is it rare? Yes.

    Here are a few thoughts on a second product:

    • Whichever product pays the bills is going to get all the attention
    • Having a second product is actually 10x more difficult that it appears
    • Finding product / market fit still takes 12 – 24 months with the second product
    • Micro apps that are a subset of the mothership’s functionality are fine as long as they share the same code base
    • Building a successful second product suffers many of the same issues as being a part-time entrepreneur
    • If it’s going to be done, consider having a separate, dedicated team of people and website devoted to the product

    When the first product has plateaued or is in decline, a second product makes sense to try and start growing again. Regardless, startups should stay away from a second product as long as possible.

    What else? What are some other thoughts on a startup having two products?

  • Mobile Apps Preferred Over Hybrid Marketing Web Apps

    Quick, what are some common tasks you do regularly on both a native mobile app and in a standard web browser? Now, do you favor one interface over another? I’ve found myself using the native mobile apps more frequently than the web apps, even when sitting in front of my laptop.

    Here are some example services where I prefer the mobile app over the browser interface:

    Looking at the apps, the main reason I prefer the native mobile version is due to the streamlined nature of the user experience. The web apps work fine but they’re a combination of full application and marketing site, making it more cumbersome to complete the most common tasks. With a native mobile app, there are fewer features compared to the corresponding web app and use of context-aware features like the phone’s GPS improve the experience even more. Over time, look for mobile apps to grow even more important as the go to way to get things done.

    What else? What are some native mobile apps you prefer over the web version?