IEEE HomeSearch IEEE ShopWeb Account Contact IEEE IEEE
MembershipPublications/ServicesServicesStandardsConferencesCareers/Jobs
Spectrum Online

 



View Current IssueSearch IEEE SpectrumJob SiteEditorial StaffAdvertisingDirect Mail Lists
Wednesday, 31 December 2014 Home » Careers » Manage & Hire



news
Careers Archive
People
Manage & Hire
Education
Career Strategy
News & Trends
Workplace
Intellectual Property

tools & resources
Newsletter Signup
Newsletter Archive
Company Profiles
Find a Job
Post a Job
Today's Engineer
IEEE Careers/Jobs
Event Calendar
IEEE Conferences

services
About IEEE Spectrum
Subscribe
Contact Us
How to Advertise

education
m021405

The Battle Over Product Development

Bring a new product to market is never as calm and orderly as the textbooks lead you to believe

By Frans M. Coetzee

Editor's Note: This is Part 5 in Frans M. Coetzee's series "Here Be Dragons: Managing a Tech Start-up," which discusses the pitfalls and glories of starting up your own tech company.

What most distinguishes a start-up from a large corporation is the intertwining of the development cycle with sales and marketing. The resulting friction seems to be universal. As one start-up CEO lamented when asked which question he really needed answered to make his business flourish: "Can't we all just get along?"

The development cycle in textbooks presents a calm, orderly process of gathering input, specifying appropriate functionality, developing the product, testing it, and then rolling it out. A relatively complete product is periodically handed over to sales and marketing for internal review and limited market testing, following which release versions are honed and delivered for final sales. In this idyllic world, resources and deadlines are generous enough to ensure that the development timeline is always on track. Sales staff have adequate training and supporting product documentation.

In contrast to the ideal model, in a tech start-up, you will be developing functionality that has to be rapidly completed for the company to survive, while the sales staff will be doggedly trying to sell the fugitive whiff of undeveloped functionality. Thus, the development cycle suffers from two major sources of friction: one, sales and marketing confusing raw customer input with specification control, and, two, technical staff not accepting the business and funding pressures.

In this article I will discuss how to better coordinate the development process with sales and marketing. Since the CTO directly controls the development cycle, the view here is slanted somewhat to the technical side. However, the CEO should understand the process so as to be able to curb his or her own tendencies to cause harm, as well as to be ready to back up the CTO.

First, a word to the wise. Feel free to be somewhat dictatorial with the technical team at the start. A core technology that does not reflect a single vision is a disaster. Also feel free to seek input, but take aboard only those ideas that have a clearly identifiable benefit. Ideas that cannot stand some heat from you are not worth the loss of the single coherent viewpoint you should have developed in your months of planning. Small errors of interpretation at the start will grow over time, and their elimination is worth a few ruffled feathers. Staff should pursue their pet ideas only when the foundation is no longer at risk.

Spend your primary development budget within nine months. The golden rule in technology is that functionality is equal to resources multiplied by time. Usually, you will find that given a chance, the business side and the venture capitalists will try to conserve cash and push down development cost and perceived risk, and hence resources. Especially deadly: "Let's go slowly until the market validates our model." Striving for just-in-time development is a surefire way to end up behind schedule and with a poor product. The developer will logically (but naively) accept the promise of an increased timeline or limited functionality. This pact is never honored. Nine months is the maximum time that sales will sit on their hands without generating debilitating commitments. Beyond that point, significant movement (or visible functionality) usually will have to be demonstrated monthly, and right there you will be in trouble. Either a crisis will be generated by sales staff, who when confronted by a slow-moving product skeleton will melt down like cranky toddlers, or if things are going well, will be tempted to add or infer more functionality.

In line with the above, executives should never allocate development resources at critical minimum levels or underfund staff. Inevitably some unforeseen problem or delay will crop up, and you will have no spare capacity to recover. If you are allocated a new staff position, hire that person as soon as humanly possible. Use it, or lose it. Remember, as semiconductors taught us, a hole also carries a charge (or in this case, a commitment).

While development takes place, business people have to stay busy. Usually, they produce PowerPoint presentations or they talk to customers. In some cases, valuable feedback results. In most cases, however, they will generate extraneous requirements, commitments, and demonstration events. They may even accidentally sell the product. But you can stake your bottom dollar that an advance sale will not be according to agreed upon specifications or timelines. Both the CEO and CTO should assume that the phantom functionality that sales envisions will grow by 50 percent during the year based on business feedback—and that this 50 percent will be seen as primary, built in lieu of the product's foundations.

Everyone should understand that deadlines are ultimately under the technical staff's control. When the business side sets deadlines or controls the deliverable scope, especially in response to vague customer commitments, you are in free fall. The reason for this is simple. Business deliverables are almost never concretely specified and can therefore always be met. For example, promising a report or a phone call by the end of business the next day is simple. The call that is produced is by definition what was required. I have never heard of an MBA promising a 61-page report matching a 22-page specification and test plan with a list of measurable specifications. The more likely scenario is a report delivered in PowerPoint. Most business people also have never dealt with a problem where the system works only when 100 percent of functionality exists, or where a single bug means that you cannot ship. Hence, they frequently create a house of cards based on interdependent commitments that they're unaware of. You will miss one delivery, sales's little house will collapse, and you will be buried under the debris.

The CTO should make it clear to the rest of the company that the technical side has a voice that needs to be heard after sales or marketing float an idea. Sales and marketing people will tend to see anything less than the tech side screaming "No!" as a bona fide commitment to delivering functionality.

Never agree to, or deliver, functionality that was not explicitly scoped and documented. And never end up in a situation where each customer-facing individual views the development team and their priorities as being solely answerable to him or her as needed. The latter is especially likely when your product requires customization or installation.

Unless a clear crisis is evident, never change or allow review of major functional specifications more frequently than on a quarterly basis.

If the business executive or sales staff tells you that it is the sole responsibility of technical staff to "manage expectations" or "tailor communications to limited understanding" for sales and operations, you are in deep trouble. Strenuously resist this fallacy at the earliest opportunity. At best it is a sign of laziness on the part of the business side. The first time someone pontificates to the CTO about an error having been caused by "too technical" a communication, make sure that person's only remaining expectation is to be buried in a pair of tastefully matching socks. Deal with the converse attitude in a similar fashion: do not excuse technical staff who ignore basic business communications and constraints.

Few nontechnical people adequately understand multiple hidden levels of dependency. They see only what is visible to the user. Resources for extending a product's foundations are therefore always in peril. The CTO should do what is necessary to ensure that the CEO supports him in protecting the fundamentals.

The CEO should never allow customer contracts to be priced until a product hits the quality assurance phase. Customers, as well as your own sales staff, will discount an incomplete product. Worse, you will be sidetracked on functionality that both groups add on to feel comfortable with their earlier decisions and pitches. Such changes can play havoc with the financial plan, when upgrades and premium-version functionality get pre-sold at steep discounts. Eventually, the executives will have an uncomfortable interview with the board to explain why the company's profit margins have fallen.

Quality and commitment are the unrecognized major differentiators in the current economy. The idea that we live in a fast-moving world that precludes deliberate planning and execution is nonsense. If it really were possible to build a product worth billions in six months, someone would already have done so. Dangerous optimists who harbor this get-a-killer-company-to-market-lightning-fast belief simply do not consider the support and cleanup costs. A start-up is a risk game. You play it by looking carefully, then putting your chips on the table. Day-to-day variations and insights cannot compare with the amount of thinking you should have done during the planning phase.

As CTO, the best way to treat technical staff is to serve as a buffer between them and the rest of the company. Responsibility should always be matched with authority. Therefore, know that your executive management functions cannot be delegated, and be extremely wary of relinquishing all technical decision making. Never assume that a technical staff person will have strategic insight when that person has been shielded from the everyday turmoil and feedback coming from the business side. However, to balance their blissfully shielded existence, take no prisoners when the technical staff miss deadlines or deliverables.

In the standard development models, lack of time for testing is always bemoaned. My personal bane, however, was to discover that technical documentation was not produced by the business side, nor were run-time cost estimates, nor production documents such as user manuals and cut sheets. Even if ultimate responsibility is assumed by some higher corporate power, the developer or CTO will have to make the drafts. Make sure this production is factored into timelines, as well as the normal buffer for testing.

Finally, having worked extensively in software companies, I would like to close by mentioning three golden rules that will markedly improve your software development cycle:

1. Never let a developer design a user interface. Get a good graphic artist.

2. Never let a graphic artist design a user interface. Get a good developer.

3. Don't build software that requires a user interface.

About the Author

Frans M. Coetzee received a Ph.D. in electrical engineering in 1995 from Carnegie Mellon University in Pittsburgh. In 2000, after stints as a researcher at Siemens and NEC, he cofounded Certus International SA, a security software company, which was later acquired by GenuOne Inc. He served as CTO for both companies through August 2003. He currently works on Wall Street.

 


 

 
Copyright | Terms & Conditions | Privacy & Security | Contact | Top