Battle Over Product Development
a new product to market is never as calm and orderly as the textbooks
lead you to believe
By Frans M. Coetzee
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
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
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).
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
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
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.