The Startup Hats: The Introduction - 1

{{ story.headline }}

{{ story.subheading }}

{{ story.timestamp }}

David Gardner is a serial entrepreneur and angel investor based in Cary. He sold ProviderLink to Compuware for $12 million in 2006. Four years later, he sold Peopleclick to a New York private equity firm for $100 million. Among his portfolio of 25 local startups are FilterEasy, Stealz, Validic, ArchiveSocial, FotoSwipe and Fortnight Brewing. He had two exits in 2013: Magnus Health (after it raised a round) and ChannelAdvisor.

Gardner wrote The Startup Hats over Christmas 2013 and expects to publish it. In the meantime, he shares excerpts of each chapter with ExitEvent readers in 13 installments. Here's part four.

OK! You've built a reasonable business model. You know how you are going to manage cash flow and you've managed to raise the necessary startup capital you'll need. Now, it's time to put on your construction hat and finish building that product. This chapter is geared more specifically to building a software product, but most of it is applicable to building any product that has various features and functions.

Even if you are a seasoned software developer, you may struggle with writing system specifications and product management, simply because these are very different skills from coding. Most software startup teams think that their product has to include much more functionality than it actually needs before they can start selling it. I encourage teams to avoid scope creep and get to a minimum 1.0 release as quickly as possible. It can be sold as a "beta" to set customer expectation. There is a catharsis in actually selling what you have and it most often leads to many great changes to design and prioritization that would not have happened had you not sold a minimalistic version first.

You can spend a lot of money building in features and functionality that do not really create significantly more value for your target market(s). There are some simple, but effective ways to ensure that you are spending your R&D dollars effectively. You need to constantly manage the value (sales benefit) of each proposed product feature against the cost (R&D time). Once again, it's time to whip out your trusty spreadsheet and start building your product roadmap.

Determining and prioritizing your product's features

The first column header should be labeled "Feature". The second header should be "Value", then "Cost", and finally "Priority". List every proposed feature or functionality that you can think of on a separate line in the first column. This is just a brief few sentences to remember the gist of the concept. List every idea that anyone on your team has thought of or heard a customer mention.

The Startup Hats: The Introduction - 1
Research competitive product offerings and list features they have if you think they are pertinent. This is the master feature list. It's best to use a shared spreadsheet that everyone on your team can assess and contribute to, including your advisors with related industry subject matter expertise. Don't leave it to chance. Make sure everyone knows that the minute they think of something, it should be captured and documented before it is forgotten.

To the right of each feature description is its sales and marketing "value". How much do customers want or need this feature? Is it critical or just a nice whistle or bell? Will they buy the product without this feature? Are there prospects who say they would buy your product if it had this feature? Do competitors offer this feature or capability, and if so, do they tout it giving it much press? The value scale can be whatever you think works best from assigning a letter value to using a drop down box of descriptive superlatives. When a feature is first listed, you may not know its value and this will have to be filled in later by speaking with your beta customers, industry advisors, and other research.

The final column is for "cost". Each feature needs an assigned best-guess cost in development hours. If your CTO or team leader estimates that two developers could complete a certain feature in about two and half days, then the cost of that feature is five development days. I'll discuss the difference between the product manager role and the CTO/developer manager role in a moment, but for now, it is important to note that whoever is responsible for managing your coders is the person who should come up with these time estimates. This person will know his or her team and each member's strengths and weaknesses given a particular task. The estimate should be conservative and include the time necessary for quality assurance (QA) testing, data migration, modification to hover and other help screens, training material changes if applicable, and basically everything required to push that code drop into production.

Cost matters.

We've all heard that time is money. Nowhere is this truer than when you are wearing the construction hat. If you are not the person coming up with the estimates, you can do a lot of sweating under that hat. Time is precious and you will feel a huge sense of urgency each day as your pre-revenue working capital plummets. If you are not contributing as a coder, you will feel rather helpless waiting for the features you need in order to start producing revenue. It will be difficult, but I encourage you to always accept the estimates provided by your CTO without question. Never use those early estimates to criticize him or her or the development team. The features on the high level roadmap are not well defined and once they are defined in a specification document, the amount of time necessary to deliver them can vary dramatically.

Imagine being forced to estimate the cost of building a house from only a two to three sentence high-level description. Estimating software deliverables can be a very humbling exercise, even for a very experienced CTO or team leader. Sometimes an open source module can be located and implemented that knocks literally days off of an early estimate. Other times, coders can run into unforeseen complexities that bog them down for days.

Your CTO will not like giving you any estimates based on the few sentences listed in the high level roadmap, but you must have at least a ball park cost estimate for each one. You should reassure your CTO that you understand how difficult this is and that you are not going to hold him or her to this best guess. This first estimate is just to help you or your product manager (who are probably one and the same) to decide which features should have a full system specification written.

Your features list may seem overwhelming, but it is important to capture them and to keep them in mind as your development team architects your product. If they know that certain features might be added at a later date, they will often design the data model, interface and other parts of the system differently, in anticipation of having to support these features in the future. They may even stub in and comment where certain features connect once built. The more heads up you can give the development team, the better decisions they will be able to make and the less costly code-refactoring you'll have to do in the future.

Once you have a first pass cost estimate on high level features, it's time to select which features will be in your 1.0 release and write detailed specifications for them. Some features are a must-have, while others should be selected on the basis of highest value (sales benefit) for the lowest cost (R&D time). If you feel that you need more time to research the sales value of a feature before prioritizing it, then finish the specs you can and get the developers started on those. Remember, you want the most minimalistic 1.0 release possible.

Set roles and commit to them.

As a founder or co-founder of your startup, there is a good chance that you are the acting product manager. If you are going to wear this hat, it is important that you understand the gravity of this role. Your company will be no better than its flagship product. The product manager's job is to maintain the high level roadmap and to write detailed specifications for each feature before giving them to your CTO for development. If you are the CTO coding and leading the developers, then I would suggest that you avoid being the product manager. It is extremely rare to find a coder who can view product features and the user experience the way a non-coder can. Products designed by coders typically have a user interface that is a reflection of the backend procedure calls and architecture, rather than one that intuitively mirrors the business work flow and the way non-technical users would think the application should flow.

As product manager, your job is to ensure that the product is as easy to sell as possible, as quickly as possible. You will constantly be prioritizing the high level roadmap based on new information. For example, your sales team might go to a trade show and find that a high number of prospects asked about a particular feature. Or, you may read in a trade journal that a certain report is likely to be mandated by the government or certification authority next year. A product manger is constantly searching for bits of information that can fill in the blanks and help to clarify how things should be prioritized. Good product managers are perpetually contacting customers and asking them what features they like best or least, and what functionality they would most like to see included in the next release. They host focus groups and immerse themselves in the industry their product serves.

In the early days, the product manager is also the guardian of the user interface. Before a new release is pushed, product managers will often bring in groups of users to see if they can use the product as intended with little or no assistance. You'll need to watch intently at training classes and demonstrations to see where a new user's forehead crinkles in confusion. Wearing this hat means being fanatical about the user experience because, as your company grows, even a small non-obvious part of the interface can lead to thousands of frustrated customers and costly support calls.

Have a plan but be prepared for everything.

Unlike a written business plan, a written detailed product spec is imperative and one of the most time-consuming and meticulous tasks you will face while wearing the construction hat. In many cases, as much time should be spent writing the product specification as is spent actually writing the code. The problem with developers is that they tend to give you what you ask for! Every use case must be considered. Here are a few use cases to give you a feel for how meticulous developers have to be:

UC1: User selects function one i.e. any function your product enables
UC2: User selects function one but has not created an account yet
UC3: User selects function one but has not completed a required prerequisite
UC4: User selects function one but has not been granted administrative permissions for this function
UC5: User selects function one but decides not to complete the process once begun
UC6: User selects function one but looses internet connectively prior to completing the process
UC7: User selects function one but then decides to also include X on the fly

You get the picture. Every use case has to be thought through in detail. What will you allow? What will you restrict? What various paths and error messages will you provide? The functions that will be performed most often should be the easiest to perform, the default, or built into the template. Any cases you do not document will be like an open hole in your application, waiting to trap and frustrate your users, or even worse, crash your application and corrupt your data.

Developers should always have good written specification in front of them. Developers without clear written specifications and a target deadline, will often begin to develop their own functionality or tangential projects; such as rewriting a section of their code to see if they can achieve the same functionality using less lines of code or a more creative algorithm. Developers take pride in their work and if given too much time to polish, that last 5% can double the required R&D hours.

Trust and listen to your technical people.

Features are prioritized on the high level roadmap spreadsheet. In prioritizing features and releases, you have to weigh the sales and marketing benefits of each proposed feature on the roadmap against its R&D cost. It's not as simple as it sounds. Some features may logically have to be completed before others and there are tasks that will need to be done in support of product scalability and robustness that aren't even on your new feature list. Product management is the bridge between R&D and S&M (sales and marketing). You can't rearrange the roadmap every time a sales person hears about some feature a customer wants, even though most sales people really do think you should.

Listen to your CTO when he or she tells you that time is needed for non-feature related coding. As your coders push to get new features shipped, they may not initially be able to include all of the scalability, security, and monitoring features that they would like. You have to make the hard decisions from time to time giving them some time to catch up and write important code that is not feature related. If you don't, then you're just building a house of cards that will eventually collapse and ruin your company's reputation.

It is always best to maintain a continuous dialogue with your CTO when it comes to product specifications and prioritization. Never just hand your written specification to your CTO. I always made a habit of asking my CTO to iterate back and forth with me on a spec. An experienced CTO will have good suggestions such as, if you can live without this little part of your spec, then we can reduce the estimated development time by fifty percent. At this stage, the spec is a dialogue. The CTO needs to understand what parts of the spec are a "must have" and you need to know where potential time/cost savings might exist. Feature specs should go through a few revisions before being finalized and handed off to developers for coding. This will ensure that you are getting the most value for your R&D dollars.

After your initial product launch and as your customer base begins to grow, you will need to start maintaining another important continuous dialogue with the person doing or managing your support/help desk. It's everyone's job to find and report bugs, but your support manager will be most familiar with which bugs are causing your customers the most pain and frustration. With each new product version release, the most severe bugs should also have fixes prioritized along with the new features. These are tough judgment calls and lots of people will have strong opinions about this. Listen to everyone and then make the calls you see fit.

Managing a product from its initial release through the early updates and new releases, is where the real magic happens that will either make or break your fledgling startup. If your product is endowed with too many features, then you are paying too much for R&D and probably parting needlessly with equity to fund it. If the product is too light on high value functionality, then your sales team is going to struggle and your revenue numbers won't show the traction you need, thus leaving you once again parting with equity to raise more capital to get it right. In the early days in particular, it's all about product management and finding the right balance for each release.

As the CEO, you job is to trust, but verify. Your CTO should be enforcing a coding methodology that is efficient, extensible, scalable, robust, modular, and well-documented. He or she should be doing code reviews periodically with developers to ensure a quality product. Along with many other duties, your CTO should be putting production-monitoring tools in place, as well as procedures to ensure automated warnings for quick recovery and maximum up time.

If you don't have the background to evaluate your CTO, then you are going to need some insurance. I recommend having an advisor or firm do a periodic review of your company's code and processes. A competent and confident CTO should welcome the assistance and oversight. Make sure that you get a full report. Your company can survive almost any bad hire, but nothing will sink you faster than a CTO that launches you on a faulty foundation. Get an outside opinion from time to time and don't hesitate to demote or replace any member of your management team who is jeopardizing the venture.

Beta testers are your best friends.

As I mentioned earlier, it is important to try to get a minimalistic initial release to market as quickly as possible. You should have a good group of beta customers advising you as to what features are most important and why. Beta customers are eager early adopters, who, with proper expectation setting and careful listening, can become your greatest asset in building a solid product offering.

They will also become your most loyal references. You probably ran into several of these while researching your idea. Everyone loves the startup honeymoon stage. This is the time before you deliver anything when everyone is excited about your pristine idea and potential. It's easy to win over beta customers if you position them as informal advisors. You want to build a product that solves a problem they understand all too well. You need their advice, and in exchange for that, you will give their organization free or discounted pricing for a time. I usually start with free, but leave the door open to charge them a discounted or "most favored nation" price once the product is fully functional.

Positioning early beta customers this way is crucial and very doable. Everyone wants bragging rights that they helped design some software system that solved a real industry problem. They want to be able to say that they were an early part of a company that really took off and did great things. Since you are not asking for money, their approval process can be quick and simple. They are the best customers you will ever have because when they use your pre-released product and find all sorts of bugs and missing features, rather than being angry at you, they will feel good about it because they are just doing what a beta customer/advisor is supposed to do. When you are ready to ask for money, you will usually find them emotionally committed to the product because they helped to build and perfect it. When you are ready to launch your first non-beta release, you will already have great customer logos on your website and a page of solid references for new prospects to call.

Make sure you nurture these precious relationships throughout the beta process. Speak to them often and get their take on specifications and early user interface mockups. Be grateful and whatever you do, don't argue with them over anything. Some beta customers will want you to include functionality that is useful exclusively to their company and literally no one else. Obviously, such features, if they even made it onto my roadmap, would be way down at the bottom of the list. I deal with these issues very respectfully, but explain that such features will have to be considered in a future release. Usually this is enough to side step the issue without losing one of your precious betas. Whatever idea they have, assure them that it is a great idea and one you will add to the roadmap for full consideration at the appropriate time.

Remember to ask for things up front to set a beta customer's expectations. I use conditional logic because people are usually more willing to agree to a theoretical or contingent request. I phrase my request something like this, If we do a good job and build a great product that really does meet your needs or solve this problem for your company, would you be willing to champion and try to implement this solution throughout your organization, serve as a reference, publish a case study with me, etc.? This seems fair when presented this way. It is much easier to get beta customers to do things for you later on if you have already got them to conditionally agree to do so in advance.

Early stage product companies tend to push regular new releases. They have to in order to fix bugs and to make major missing features available, but over time the version release cycle should slow down dramatically. Each release or push to the web, requires a full QA testing cycle. If you are supporting multiple browsers, tablets and mobile platforms, each has to be tested again with each release. Before long, you have a very large spreadsheet of test cases that can require many days or even weeks to verify. So as the product grows, you will want to have fewer, but much larger version releases and try to minimize the inefficient QA cycles. Make the most of those early days and quick release cycles because they will not last and you will not be able to innovate as quickly in the future.