David Cummings on Startups

Category: Product Mgmt

  • Publishing a Product Roadmap

    Cabbage Market
    Image via Wikipedia

    One aspect of our annual user’s conference is publishing our product roadmap. Now, we don’t publish our entire roadmap as the market is too dynamic and we’d rather under commit than over commit and have to remove functionality. The challenge is to balance the desires of customers, employees, prospects, and the general vision for the application. Most important, it is critical to be opinionated about the software.

    Here’s what we consider in building our product roadmap:

    • Internal vision and opinion for the software
    • Customer ideas and votes on our idea exchange
    • Services and support team member input on ways to make their lives easier
    • Marketplace input from prospects and analysts

    My recommendation is to make the roadmap development process a regular strategic action item.

    What else? What other aspects would you add to the product roadmap process?

  • Hold an Annual User’s Conference

    Georgia Tech Yellow Jacket cheerleaders at a 2...
    Image via Wikipedia

    Every year in the Fall we hold an annual user’s conference. In fact, our conference for this year is right around the corner. The user’s conference is one of the highlights of my year as it is the best time to meet with many clients over a two day period. Our business model is primarily selling direct with an inside sales team, so we rarely meet prospects and clients face to face. Over time we build rapport with our users as our services, support, and engineering departments regularly interact with clients, but there’s something lacking without face time. An annual user’s conference fills that gap.

    Here are a few benefits of holding an annual user’s conference:

    • Cheerleading – Provides a great experience for team members to understand how much customers really value what we do
    • Feedback – Allows us to capture feedback and input on how we’re doing and the direction of the product
    • Excitement – Gets customers energized about our software as well as helps with any challenges they might have encountered

    Now, a user’s conference is a big production and takes considerable planning. I’d recommend ensuring at least 30 people can attend (we average a little over 100 people at our conference each year). My advice is to seriously consider having an annual user’s conference as my experience with them has been exceptional.

    What else? Have you hosted or attended a user’s conference and found it valuable?

  • Benefits of a Third-Party Code Audit

    Software (novel)
    Image via Wikipedia

    One of the things a startup should do early on, if they can afford it, is a third-party code audit. The nature of software is such that suboptimal architecture decisions can lead to significant rework in the future. If best practices are followed from the beginning, functionality can be implemented at a faster pace. Here are some benefits of a third-party code audit:

    • The auditor reviews many projects and can share common best practices
    • A new set of eyes will see things that get missed with tunnel vision
    • Improving the code while the base is smaller will pay dividends in the future

    For example, if you have a Rails project you should talk to the good people at High Groove Studios. My recommendation is to consider a third-party code audit if you have any concerns about your current code and you have the money to afford it.

    What else? What are some more benefits of a third-party code audit?

  • Launch Fast, with Minimum Viable Product

    Watt's steam engine at the lobby of the Higher...
    Image via Wikipedia

    As part of the lean startup movement and customer driven development, the concept of a minimum viable product is one of my favorite components. I’m a big proponent of launching fast: less than 90 days from starting, a web services company should go live with their product.

    Now, 90 days isn’t much time, and it isn’t alway possible to launch that fast, but having a constraint in place where the engineering effort is time boxed really forces you to strip off functionality and deliver a minimum viable product. All too often I see engineers so wrapped up in their product that they keep thinking they need to add one more feature, when in reality they don’t have enough market feedback, haven’t achieved product/market fit, and are building a product without a market. I’ve been there.

    My recommendation is to get the product out the door as quickly as possible, with the bare minimum functionality that still makes it useful. With that in place, work hard to acquire customers, preferably paying, and then learn what their needs are, and incorporate that into your opinionated software.

  • Account Sign-up Page Best Practices

    A few weeks ago I was helping an entrepreneur who was getting ready to launch a new site. He took me through the product functionality, the website, launch strategy, etc. When we reached the account sign-up page it was a disaster. An interactive agency had designed it, and it looked aesthetically pleasing, but it wasn’t designed for reducing friction in creating an account.

    Here are some simple best practices for account sign-up pages, which in many ways should be treated like landing pages:

    • Remove all unnecessary links, which are usually 90% of the ones of the page.
    • Minimize the header and text as much as possible. Then, cut it down even further.
    • Reduce the number of fields, especially required fields, to the bare minimum. Once you have someone’s email address you can always market to them later to fill out more fields.
    • Keep all the fields in the form above the fold so that the user doesn’t have to scroll down at all. Test and enforce this on monitors with a 1024×768 resolution.
    • State clearly that you value the person’s privacy and won’t sell or share their information.

    With these best practices in place, conversions typically increase 10%-50% over a normal sign-up page.

    What else? What are some other best practices for designing an account sign-up page?

  • The Difficulty of Modernizing Legacy Software

    Outline of a cloud containing text 'The Cloud'
    Image via Wikipedia

    As part of my recent project researching ideas on building high quality prospect lists, I reached out to several different providers. One of the companies had a really promising product that allowed for slicing and dicing data, presumably from Dun & Bradstreet or Hoovers. After getting excited about their technology, merely based on their marketing collateral, it came time for the product demo from a sales rep.

    Guess what?

    The application with a Windows product with no web-based components at all. Their response to the question about them building a Software-as-a-Service product: no plans at all. Now, I don’t know how successful this company is but it was pretty amazing to see a product that clearly should be in the cloud, connected to CRMs like salesforce.com and SugarCRM, and all around part of the normal web ecosystem.

    The point here isn’t what one single company should do, but rather the difficulty of modernizing legacy software. Once companies become successful with one product, working one way, it is incredibly difficult to introduce a new or modern product built from the ground up.

    With difficulty comes opportunity. Startups don’t have the legacy baggage of code debt, existing customer needs, and the status quo. Wherever you see a legacy system that is still continuing along, there’s room for a startup to do a modern version of the product, in the cloud, and be successful.

  • SaaS Products with the Same Name as the Company

    One of the many exciting decisions to make when starting a company is the name of your first product. For many software-as-a-service (SaaS) companies, the product is synonymous with the company and is referred to as the same name as the company. Depending on if you’re taking a multiple product approach vs a single product approach, it is important to think through the product naming convention.

    Some companies like GE name every division using the company name followed by a word specific to what they do e.g. GE Energy, GE Capital, etc. Other companies like P&G have different brands for their products and don’t co-brand them with the P&G label e.g. Tide, Bounty, Duracell, etc.

    My recommendation for SaaS companies is to call your main product the same name as the company and keep it simple, or add a generic term after it like “App”, “Suite”, or “Platform.” Once you are successful your customers and users will identify with the company and not the individual product.

  • Dialogue with Enterprise Software End Users

    One of the challenges with product management and certain enterprise software products is creating a dialogue with end users. Often the product purchase and management is driven by the IT department, which also administers the application. Administrators then become the contact points, but don’t use the product in the same way as their end users.

    Here are some ideas to address this issue:

    • Include a prominent link in the application requesting feedback
    • Have an idea exchange for users to submit ideas
    • Do quarterly check-in calls with customers and ask to speak with end users
    • Invite admins and end user to a user conference

    My recommendation is to work hard and create relationships with the different types of product end users.

  • Don’t Reinvent the (UI) Wheel

    One question I hear a good bit from software entrepreneurs building their first product is “Who made your user interface?” There’s a dearth of quality user interface (UI) and user experience people, especially in markets like Atlanta. Many people think they can get their graphic designer friend that made the company logo to also do the user interface. I’ve gone down that route and it failed.

    My recommendation is the classic R&D — ripoff and duplicate — of a major product where the company likes to have apps that have a consistent user experience with their app. That’s right, please don’t reinvent the wheel when it comes to the user interface. Companies like Google, Apple, and Microsoft have invested millions in the UI for their different products. For example, Gmail, Google Analytics, and Google AdWords have nice clean and fast UIs that are perfect for most B2B web apps.

    What else? Do you agree or disagree that most people shouldn’t reinvent the wheel when it comes to UIs?

  • Product Death by Not Enough Cuts

    In the software world, death by a thousand cuts comes from trying to make the product do all things for all people. I want to bring up another phenomenon not talked about enough: death by not enough cuts. This happens when an entrepreneur builds a product and gets it in the hands of a few customers, only then to keep customizing it further for those too few customers. In addition, it is often combined with not being opinionated enough about the product functionality, so a few companies drive the product road map.

    The next thing the entrepreneur finds out is that they have a deep and rich product, but not a big enough market to be successful. Oh, and the product is so large now that adding functionality takes significantly longer than it used to take — big problems lie ahead. Here’s what I recommend:

    • Get the product into the hands of as many prospects as possible
    • Launch early and often
    • Always ask yourself if the feature request fits into your vision for the next three years (be opinionated!)
    • After you’ve asked if it fits in with the vision, ask yourself if it is applicable to 80% of your user (e.g. will they love to use it)
    • Every 20 customers you sign up, raise the price until you can’t raise it anymore

    What else? Have you seen this happen? What would you recommend?