David Cummings on Startups

Category: Product Mgmt

  • Transitioning from Services to Products

    Today, I had the opportunity to meet with a successful entrepreneur who is working on transitioning his 18-person company from services only to a mix of software products and services. I think this is a common occurrence with service businesses: the business owner gets tired of selling labor-intensive work and looks for product ideas related to his or her core competencies.

    I offered up the following advice:

    • Hire completely new people to work on the product. It is very difficult to transition existing people out of their current roles, especially if you don’t already have excess capacity in the business.
    • The best new product development teams I’ve worked with combined a full-time marketing product manager and a full-time lead software engineer (you really only need two good people to prototype normal web apps).
    • Plan for it to take a solid three to six months to get the first worthwhile beta release into the hands of potential users.
    • Budget for 12 – 24 months of expenses to see the new product through to product/market fit.

    I haven’t done it, but I can imagine transitioning from a services company to a services and products company is very difficult. I hope he’s successful!

  • Deciding to Build a New Product

    After today’s entrepreneurship talk for one of Emory’s MBA classes, several of the students lined up to ask me questions. One of the questions was essentially “Do you have a finance person that helps decide when to build a new product?” I quickly said that we didn’t have a finance person help us decide and that it was still based on a gut decision and customer driven input.

    This provided a good segue into describing what I think is necessary for new product development and what I think our core competency is as a company. As for a new software product, assuming you are already following Steve Blank’s advice, I think it is critical to have a domain expert product manager and a separate lead developer software engineer. With today’s awesome web app frameworks, a small, two person team can really put together a prototype of just about anything. In my company, I believe our core competency can be distilled down to three main areas:

    • Scalable web applications
    • Online lead generation and marketing
    • High quality customer service

    So, while I don’t have more specifics on deciding to build a new product, I look at what we do best generally, solicit feedback on the idea from internal and external stakeholders, and then make a decision one way or another. Also, don’t be afraid to kill a product if it isn’t going to be successful. We stopped development of a product over two years ago after working on it for several months, and we should have stopped even sooner.

  • Product Management Approach

    With a fast-growing technology company, the challenges of product management crop up on a regular basis. It is tough to balance desires and ideas from prospects, customers, partners, sales, support, services, engineering, analysts, and competitors. We’ve learned a few things over the past nine years related to product management.

    At my company, we’re always learning as we go. We recently implemented a change to all of our applications, where we put a big “Give us feedback” link in the header or footer of the major product screens. The feedback link points to an idea exchange specific to the product that solicits input from customers, prospects, partners, and employees. This approach has really helped gather ideas from a broader range of users, and it helps the best ideas rise to the top by way of the voting process.

    We also have a full-time client advocate for each product line who reaches out to customers to proactively solicit feedback. Our client advocates are awesome at doing quarterly check-ins, answering questions for clients before they need support, and being contact points to help get things done. Also, our client advocates represent one of the voices in our product roadmap decision making process.

    Internally, we have a 24 month unpublished product roadmap. Why don’t we publish it? Well, we’ve published it in the past, only to consistently have at least 20% of the items on it change. This causes consternation for clients who were anticipating a specific feature. A roadmap is very important, but we’ve learned that being fluid and agile with respect to continual feedback and market input is even more important. The world changes fast, and so do our plans.

    These are just some of our main approaches to product management. Product management is a tough discipline that requires synthesizing input from many stakeholders, and is more of an art than a science. Someone once said “the product is the marketing” and I couldn’t agree more. The product is the marketing and product management is one of the most important things any technology company will do.

  • Iterating in a Startup – Part Two

    In Part One, I outlined the first iteration of the Hannon Hill business model where we built a SaaS web content management system and launched it in the summer of 2001 for $30/month/website. After realizing there wasn’t a reachable market that was large enough for us to be successful, we quickly changed to an installed model of the same product. To our excitement, we sold our first $1,000 license by the end of August and thought we had a path to growth and profitability.

    Over the next 24 months, representing the life of the application, we sold 25 licenses. That’s right, selling slightly more than $1,000/month worth of software doesn’t make for a good business. Our big break actually came in December 2001 at the Internet World trade show in New York City, and was a result of changing to an installed software model.

    At the trade show, we serendipitously met another, much larger software company that was explicitly looking for a content management system to sell to their installed client base of over one million licensees. We had several rounds of discussions with their management team at the show and eventually consummated a deal in the Spring of 2002 to license our product for them to sell under their own brand name. They would pay us money up front along with a royalty for each license sold. We had our first big break.

    Now came the next big iteration: we completely shelved our product that we had spent two-and-a-half years building in order to build The Next Big Thing. By the Summer of 2002, we knew we were never going to be successful selling installed PHP software to small businesses, and that a competitor with much greater resources would be selling a slightly modified version of our product to the same audience. It was a pretty easy decision to make.

    Our next move was to make a completely new, mid-market Java-based web content management system using the expertise we’d gained over the past few years. The special sauce of our new product was a combination of XML, search engine optimization, and distributed server publishing. Of course, building a next generation product from scratch allowed us to address all the mistakes we made in architecting the first product.

    Stay tuned for part three to learn how we made this new product successful, and the sales and marketing iterations that paid off.

  • Iterating in a Startup – Part One

    I’ve been hearing a good bit of chatter lately about how important it is to iterate in a startup. This generally refers to figuring out a product, market, and business model that will result in success. Of course, success means different things to different startups. For some, it is a large, market-disrupting company. For others, it is a profitable, growing business large enough to sustain a nice lifestyle for those involved. Let’s drill into iterating in a startup.

    Lance Weatherby values velocity and versatility in team members and has coined the term velocitile to label such a person. I believe that you need both a good market and flexible people to be successful in a startup. With both of those in place, iterating is a natural and healthy part of building a company.

    My Inc. 500 software company, Hannon Hill, makes mid-market web content management solutions for higher education and other industry verticals. It wasn’t always this way. When I first started the company in December of 2000, the vision was to provide a software-as-a-service (SaaS) application that would make it easy to update a generic, small business website, for $30 per month.

    The service worked with existing websites over FTP and provided a visual interface, similar to Windows Explorer, so that people could click on a file and edit it in a browser-based word processor. Upon saving the changes, the file would then be sent over FTP back to the web server, along with a backup version. The benefits of this model included:

    • No software to install on the web server or web browser
    • No up-front fee and a low monthly cost
    • Familiar file manager interface with word processor

    The software was as easy to use as web-based email. The only problem is that it was a complete failure. I started out working on the company part-time and eventually went full-time within six months. I learned several lessons shortly after going full-time:

    • The market wasn’t accepting of SaaS
    • $30 per month per site was much too cheap to build a business
    • Customers needed significant hand holding to get up and running

    At that point, I knew something had to change. By August 2001 we had retooled the product to be an installed server application (it was always a PHP/MySQL app) at the price point of $1,000 for a 10-user license.

    Stay tuned for part two to learn if our iterating paid off.

  • Pros and Cons of Free Product Trials

    We’ve been offering free trials of our software for years and have come to understand some of the pros and cons of doing so. 

    Pros to Offering Free Trials

    • Helps assess how serious of a prospect you have
    • Provides an opportunity for the prospect to interact with other members of your team (services, support, etc) and show them how great of a company you have
    • Sets prospect expectations of what the product does and aligns interests with the company, proving that it is a good fit
    • Provides a sense of urgency as the free trial will expire at a certain date

    Cons to Offering Free Trials

    • Usually more labor intensive, especially for more complex products as services and support teams need to be involved
    • Can lengthen the sales cycle as the prospect might have to get other people from his/her organization involved, and actually do real installation work
    • Some prospects will keep asking for free trial extensions, which can create an adverse situation with the sales person that wants to solidify the deal or walk away

    A couple other items of note:

    • The free trial is really a proof of concept project, and should be referred to as such
    • Before doing the trial, clear success guidelines must be set up and agreed to by the prospect (e.g. in the proof of concept, we will show x,y, and z working resulting in some benefit, and culminating in the prospect signing a contract)

    In almost all cases, I recommend offering free trials (proofs of concept).

  • Quarterly Product Themes

    One of things we do is have quarterly themes for our products. Themes are a good way to keep everyone focused on the big picture direction for a period of time. Our products’ themes for this quarter include:

    • Ease of use
    • Connecting the dots
    • Go live

    I’d recommend having one theme per product per quarter. Set the theme and then do your best to rally your team around it.

  • Don’t Add Too Many Features Before Customer Input

    This has come up two times in the past couple weeks making it worthy of a blog post: don’t add too many features to your produt before soliciting customer input. In fact, in some cases, you should sell your prospects on the idea of a new feature and/or product just to get their feedback to see if it is the right direction to go. 

    As a rule of thumb, you should be able to build and launch your web application in three months tops. If it takes longer than that, you’re making it too complicated. We made that mistake with one of our products and are now spending hundreds of hours refactoring the back-end and actually removing some features from the product. Don’t let it happen to you.

  • Product Speed as a Feature

    One of the things I like to focus on is speed as a feature. What this means is that the performance and responsiveness of the web application is an important factor in success. With the web and web browsers working over long distance high-speed connections, there are still delays and headaches that differ from standard client-side applications.

    The speed of the application should be treated as a feature and time should be appropriately allocated for the engineering team on a regular basis to continually fine-tune the application. Here are some quick tips for improving the performance of web applications, but remember that premature optimization is also a cause of failure:

    • Offloading anything that doesn’t need to be processed in the current request to be a background job
    • Use asset hosts to request things like images, JavaScript, and CSS from different hosts
    • Use memcached along with database query caches to reduce the database load
    • Make sure your HTML is compliant and conforming to the appropriate DTD
    • Use tools like YSlow to measure performance

    Good luck in making your application as fast as possible and remember that speed is a feature.

  • Product Feature Request Pruning

    In my experience the issue tracking / feature request system that you use as part of your product management strategy will quickly become bloated with lots of ideas from different constituents (employees, partners, customers, media, analysts, etc). It is important to be very opinionated with your product’s functionality and to fight hard to keep the application focused.

    One of the things I recommend doing is similar to old saying that you should give away any clothes you haven’t worn for a year: you should delete any request older than six months that hasn’t come up again in the past six months. This strategy helps clear out items that kept getting re-prioritized lower. The act of letting the requests sit there and fester creates noise — delete them now.