David Cummings on Startups

Category: Product Mgmt

  • Go Deep Instead of Wide with a SaaS Product

    Recently I was talking with an entrepreneur that was showing me his Software-as-a-Service (SaaS) product. After a quick 10 minute demo, which was crisp and complete, he started talking about what’s next and how they were moving into an adjacent opportunity. I proceeded to ask about adoption rates, what were the “must have” features of the product, and what would the benefits be if they continued to go deeper instead of wider. The core product looked good and I didn’t buy the strategy to go broader.

    Here are some reasons for going deep with a SaaS product:

    • Be the best that you can be instead of just OK on a number of fronts
    • Resources are limited, so use them wisely
    • Deep functionality to provide specific value is much more defensible than light-weight functionality
    • Specialists command much more money than generalists
    • SaaS is readily integrated with third-party products via APIs such that the idea of an all-in-one suite is not going to win in the future

    Whenever debating product functionality, always ask yourself if you’re going deeper or wider, and the vast majority of time the answer should be deeper.

    What else? What are your thoughts on going deep instead of wide with a SaaS product?

  • Rolling out Roadmaps in a Startup

    One of the more delicate, and demanding, documents in a startup is the product roadmap. After getting feedback followed by buy-in from the different constituents, it becomes time to rollout the roadmap to customers, team members, analysts, and prospects (some pre-sale engagements sell the vision of what’s to come in the product).

    Here are some ideas for rolling out a roadmap:

    • An annual formal presentation on what to expect over the next 12 months at the user’s conference
    • A quarterly customer advisory council that meets via GoToMeeting and gets a private walk through as well as Q&A of the roadmap
    • A quarterly webinar for existing customers combined with a blog post summarizing what can be expected in the next three months
    • A monthly employee-only product show-and-tell that gives a preview of progress for each item on the roadmap

    So much time goes into building and managing the product roadmap that often there isn’t enough effort put in to rolling it out to constituents. Communicating the vision is a critical part of successful startups and should not be underestimated.

    What else? What are some other ideas around rolling out roadmaps in a startup?

  • Minimize Technical Complexity in a Pre-Revenue Startup

    Early on in a startup, especially a pre-revenue one, it’s super easy to add technical complexity to the product since there’s a clean slate. With no existing users and no lock-in, there’s nothing slowing the engineering team down from incorporating a variety of programming languages, best-of-breed open source components, and more. My advice: minimize technical complexity and moving parts as much as possible, even while sacrificing elegance to solve challenging problems.

    Here are a few reasons to minimize technical complexity in a pre-revenue startup:

    • With a limited engineering team it’s important to keep things simple so that everyone on the team can substitute for anyone else (once the team grows having more specialization works well)
    • Complexity is much harder to take out than add in, so start simple, even if it isn’t elegant
    • Getting something working that customers love is much more important in the early days than having the most scalable back-end
    • More moving parts and different types of systems create more complexity for sys admin work, especially upgrades and on-going maintenance

    Some technical complexity is unavoidable, but whenever possible, it should be minimized. Keep things simple, move fast, and stay close to the customer.

    What else? What are your thoughts on minimizing technical complexity in a pre-revenue startup?

  • Continuous Deployment in Startups

    Continuous deployment is a methodology whereby software code checked into a repository for a web application is automatically sent to the production server after all automated tests pass with no other human intervention. While not being an easy process to describe, it’s revolutionary in how it affects software development. The traditional software development process, even if agile, often involves bottlenecks around manual QA, a limited number of engineers empowered to push a release, and numerous issues when major changes are pushed.

    Here are some thoughts on continuous deployment:

    • Software releases go from big productions to non issues
    • Small changes result in small issues and large changes result in large issues (bugs are inevitable, so keep them small)
    • Automated testing becomes a critical part of the development process and no longer an after thought (there’s no right answer to how much code coverage is necessary other than it needs to be suitable to the product)
    • New developers should push code to production on their first day, setting the tone for a culture that moves quickly and isn’t afraid to make mistakes
    • Config flags are an important part of continuous deployment such that code that’s being worked on, but not ready to be seen by end users, is still pushed to production during development

    Software-as-a-Service, whereby programs are delivered over the internet, makes continuous deployment possible (continuous deployment doesn’t work for installed software). With time, continuous deployment will become more prominent, especially when firms like Etsy espouse its benefits.

    What else? What are your thoughts on continuous deployment in startups?

  • SaaS Apps Can Learn from Casual Game Engagement Techniques

    One of the more common techniques to increase engagement and usage of casual games on the iPad is to provide goals or challenges each time the game is played. As an example, the three active goals in a game might be to beat your previous high score, get to level five, and purchase a digital item in the store. Some, like beating your high score, are context-sensitive and straightforward. Others, like purchasing a digital item in the store, are designed to increase the user’s engagement with different parts of the game, and set the foundation for in-app purchases.

    Software-as-a-Service (SaaS) apps should learn from this approach. In SaaS apps, it’s easy to automatically track what features are, and are not, being currently used. With this information, as well as analytics around what’s going on with usage of active features, the software could recommend new features to take advantage of as well as ways to get more value from existing features. Even better, data across multiple customers of the SaaS app can be anonymized and used for benchmarking, so that the recommendations give a context as well (e.g. you’re 5% below the average for this category and here’s what you should do to improve).

    Here are some example goals or challenges that a SaaS app might provide:

    • Create a new page called ‘about’ in WordPress
    • It takes you an average of 40 days to get paid, and for your type of business the average should be 35 days, according the QuickBooks app, so here is a best practices guide to improving payment turnaround
    • Try out our new commenting feature in a cell in one of your Google Spreadsheets

    The next time you’re contemplating ways to increase engagement and reduce customer churn, consider goals and challenges on the main application screen of the SaaS app.

    What else? What are some other things SaaS apps can learn from casual game engagement techniques?

  • Startups Need to Get Out of the Building

    Today was the kick-off for the second cohort of startups at Flashpoint, an accelerator at Georgia Tech. The day started with introductions between the new startups and their mentors, followed by a primer on startup engineering/lean startup methodology, and concluded the morning with each team introducing themselves and their business, with a business model canvas in the background.

    The afternoon assignment was to get out of the building and talk to potential customers. Here are some thoughts on startups getting out of the building:

    • Steve Blank says, “In a startup, no facts exist inside the building, only opinions”
    • Resist the tendency to talk to friends that are potential customers as your only source since their feedback is going to be tainted by their relationship with you
    • Go to where you customers are most likely to be (e.g. at a specific office complex), not just where you might get lucky to find them (e.g. Starbucks)
    • Keep the questions open-ended by avoiding yes/no questions
    • Stay focused on finding answers to your hypotheses (it’s easy to get distracted)

    Startups need to get out of the building and talk to potential customers right away. Too often entrepreneurs build their products in a vacuum and talk to customers after spending significant resources, and many times don’t have enough resources left to achieve success. Making the most of time and resources requires getting out of the building.

    What else? What are your thoughts on startups getting out of the building?

  • Handle Initial Partnership Requests Via Email

    Before startups say no to 99% of partnership opportunities you have to qualify and find out what it is the other company is actually looking to do. There’s a standard song and dance where a VP or co-founder from another company gets an intro through a mutual connection or sends a cold email asking to set up a phone call to talk about an integration/partnership/relationship.

    Too often, myself included, if it looks interesting and targeted, entrepreneurs jump on the phone and spend an hour finding what the proposal actually is and what an integration might look like. Don’t. When the quality request comes in simply reply back via email and ask these three questions:

    • What, specifically, is the proposed integration?
    • What 10 customers have asked for this integration and why?
    • What parts can you do via the standard API we already have and what parts do we need that are non-standard?

    These three questions will provide a wealth of information and save you a ton of time. Now, you still might jump on a call for 30 minutes after you get the answers but the quality of the call will be significantly better, saving everyone time.

    What else? What other questions do you like to ask when handling initial partnership requests via email?

  • Gathering User Feedback For An Established Product

    User feedback is critical for building a successful software product. As the product matures and becomes established, user feedback is easier to get, but can also become overwhelming with requests from so many different constituents. Here are some ideas for gathering user feedback for an established product:

    • Quarterly check-in calls by a client advocate or account manager to find out how things are going
    • Idea exchange with single sign-on so that customers can post ideas and vote on other ideas
    • In-app net promoter score where you ask once per quarter how likely they are to recommend the product
    • Regional user groups with a company team member facilitating
    • Annual users conference with significant customer interaction
    • Customer advisory board that does a quarterly conference call with the VP of Product Management

    Gathering user feedback with these methods is the easy part. The real challenge is organizing the information and combining it with your own vision and opinion for the product. Then, clearly communicating the direction and future functionality with the key stakeholders.

    What else? What are some other ways to gather user feedback for an established product?

  • Platform-as-a-Service Options like Heroku for Startups

    Aarjav asked about Platform-as-a-Service (PaaS) options like Heroku in the comments of yesterday’s post Cloud vs Colocation vs Managed Hosting for Startups. PaaS is great in that it offers the benefits of cloud computing with easy scaling up and down while encapsulating many of the more tedious system administration functions present when doing it yourself.

    Heroku, owned by Salesforce.com, is one of the best known PaaS providers, especially in the Ruby community (they support other technologies as well but Ruby is still the most prominent for them). As an example, if you write a new Ruby on Rails application, to run that application you have to set up an environment and maintain it. Manual setup might take an hour if you know what you’re doing or 5 – 10 hours if it’s your first time. With Heroku, you can get things running in 5 minutes in a super simple fashion and as you scale or need more horsepower the process of resizing an instance or adding more instances is much simpler than a traditional cloud or dedicated server model.

    Heroku runs on top of Amazon Web Services (AWS), so it is even more expensive than AWS EC2 instances, which are much more expensive than managed hosting which is more expensive than colocation. Out of the box, Heroku is great and fits in with my recommendation for startups to start with the cloud. Heroku does do things like kill web requests that take longer than 30 seconds, which forces code changes like using more background jobs, which is the right way to go but might cause more code refactoring sooner than desired.

    Startups using a language like Ruby and a framework like Rails are well suited to start with Heroku and graduate from there as their success permits. Startups using a language like PHP have PaaS options like PHPFog to use as well to cut down on administration time and focus on building a business. Long term, PaaS falls under specialized cloud solutions and so the same thoughts around constant availability vs burstable needs, etc still hold true.

    What else? What are some other considerations for Platform-as-a-Service options for startups?

  • Product Features that Don’t Fit

    Last week I was working in a web-based product and I came across a feature that didn’t fit. By didn’t fit I mean that it felt out of place and there’s no way it’s potentially usable by 80% of the users. I’d be amazed if more than 1% of the customers have ever used it — it’s that out of place.

    How did the feature get in the product? Here are a few guesses:

    • It was such an easy feature that it got in the product and out the door before it occurred to product management that is wasn’t a good idea
    • A client had a problem and this was support’s idea to help that one client (even though it wasn’t applicable to other clients)
    • Someone with a strong personality (a sales rep?) convinced others that it was a good idea to help close a new customer

    Much like a supertaster who picks up on disproportionate flavors in food, strong product managers quickly reject features that don’t fit. Do you have features in your product that don’t fit?

    What else? What are some other reasons features that don’t fit get into products?