Read Startup: An Insider's Guide to Launching and Running a Business Online
Authors: Kevin Ready
Notice that I have used the word
explicitly
several times. This is not a throw-away modifier to make the sentences seem more official or businesslike. I am using it to point out the contrast to non-explicit behavior (e.g., what happens by default, what we have seen other people do, what we have always done, etc.). By looking for, noticing, and then specifically responding to stimuli, we take a measure of control that would otherwise fall to chance.
Focus vs. Opportunity
Do you pursue new, unproven opportunities or do you keep a focus on what you think are your existing strengths? Don’t let a relentless focus on “the plan”
keep you from taking advantage of opportunities to make money. Doug Richard, a business mentor on the United Kingdom’s
Lion’s Den
television series, said, “My first business and many of my other businesses grew on the back of plan B or plan C or plan X.” His was a business of adaptation and seizing on the best available chance to bring in revenue. (In Silicon Valley, this is called a
pivot
.)
This tension system is omnipresent in technology companies. Every project that I have ever been involved with has abundant opportunities to run this way or that in pursuit of “better” or “next.” It is clear that one of the primary responsibilities of the entrepreneur or manager is to quickly (but gently) shoot down ideas that will distract from your purpose. I call it
skeet shooting
, and it is almost a joke between my team members and me. The tension comes in when you realize that some of these ideas are going to be real winners and deserve to be vigorously chased down and implemented. Telling the difference is a matter of experience, imagination, and paying attention.
Process vs. Agility
Nothing beats
just getting things done
when you are small and growing. Small companies are forced by circumstance to build product and rapidly make decisions as they grow. The process is often chaotic, but this agility (or ability to move, build, and adapt) is critical for them to get off the ground. As companies get bigger, however, a focus on just getting things done can cause problems.
A larger business has many more moving parts than a small one. Imagine if IBM allowed all of its employees and engineers to make decisions autonomously as to how product should be built, and to do so without consulting their peers. It would be bedlam. Chaos. At the same time, if IBM had too strong of a process mentality—with forms, documents, approvals, and meetings for every detail of its business—then it would not be able to every get anything done at all. IBM, as any other business (including yours), will need to find a balance. That balance will change as the company and the market changes.
You will find that there is a transition from the informal, non-process-oriented decision-making of a startup to more formal processes as your company grows in size.
Analysis vs. Quick Decision-Making
Another tension system you will find in business involves the trade-offs between analysis and quick decision-making. It is natural for many people to want to minimize risk by doing detailed analysis before making decisions. Others prefer to take a quick look at a situation, and start a plan in motion based on gut feeling. Again, these are both valid options, and either one may find a positive outcome across the various situations that you will find yourself dealing with in your business. The overall likelihood is that your optimal ROI will be found somewhere in the middle of this space.
I have been involved with organizations that I would accuse of analyzing too much—so much in fact that their performance suffers. I am sure you have heard the term
analysis paralysis
. It is easy to accuse folks of being in analysis paralysis when they pause to think carefully about a decision. The proof is always in the pudding, as they say, and there can certainly be valid reasons for doing a very careful analysis before leaping in and getting to work.
Certainly, the question of what is at stake will have great bearing on how much analysis should precede action in any given case. Sending astronauts to Mars, for example, should rightly be preceded by a great deal of analytical thought. As the analysis continues, the decision-makers will see that the inherent risks in the project will decrease as more knowledge is extracted or synthesized. At a certain point, however, it will be necessary to transition out of analysis and get into the “doing” phase of the project. The art here is in recognizing when additional effort begins to stop netting you additional benefit. This can be difficult because the effect of research on your outcome will not be known until later. You could spend an hour, a month, a year, or a decade putting together a stock analysis program for managing the 20-year return on your portfolio. You won’t actually know how well it works in the real world until you stop testing and plug it into the markets with real cash and then watch what happens.
Knowing how much theorizing to do is an art form, and there is no single correct answer. We can recognize the extremes on this continuum as being foolish (e.g., ten hours planning a trip to the store or ten minutes planning a trip to the moon), but recognizing your real optimization point for your business situations (somewhere in between these extremes) will be a matter of experience, trial, and error (see
Figure 6-3
).
Figure 6-3.
Certainty, too, is subject to the 80/20 rule, where it reaches a point of diminishing returns
One thing to take away from
Figure 6-3
is that no amount of planning can completely eliminate risk. If you are doing something that is complex enough to warrant a thought-out plan, then there will continue to be risk no matter how you try to eliminate it. It is interesting to note that in business and investing, as risk increases, so often does the potential reward. That is one of the fundamental truths of an open market. This being the case, if you are planning for zero risk, you are probably playing for small profits as well.
Perfection vs. Progress
When is “good” good enough? Difficult question? When do you decide that what you are working on is good enough to call it done? This is a significant problem, in that getting it wrong can result in increased costs and delayed schedule on one side, and product failure on the other. One phrase that I
heard long ago, and I must admit took me a little bit of time to warm up to, is this:
Perfection is the enemy of progress.
To get to the heart of what this means, we can look at some experiences in my recent projects.
I have software engineers working for me that love their craft. They enjoy the art and science of what they do. This is usually fantastic, but it needs to be monitored. There have been times when a schedule has slipped and when a delivery date has been pushed back—things that I would prefer to avoid. On close inspection, one reason for at least a couple instances that I can recall was because of the pursuit of perfection among the engineers. When you are writing computer code, or building something with your hands, or producing anything that you care about, it is natural to dig deep into the art of it and strive to express yourself by making it as perfect as possible. There is a balance between this and just getting the work
done
.
The conversation that I often have with my team usually ends with the following: “Will rewriting that section of code and making the changes that you propose make the company more money?” Sometimes the answer is that it will keep us from having problems down the road. This can be quantified as the avoidance of future costs. On the other hand, the more frequent answer is a simple no. In those cases, I will ask for the code to be made good enough and to move on.
In almost all cases, doing a job as well as it can possibly be done will not make you more money. Again, the 80/20 rule comes into play (see
Figure 6-4
).
Figure 6-4.
Quality will increase quickly up to about 80 percent, then reach a point of diminishing returns
The art here is again to recognize where the point of diminishing returns is, as it will not always be clear. A delicate consideration that comes with this cutoff of effort is that the more artistic or professional of your employees will be denied an element of satisfaction if they are not allowed to proceed further up the perfection path. It is a matter of incentives. As a business owner, you need to make money. A significant part of the benefit that a good employee will get from their work is a sense of accomplishment and self-expression. Needing to enforce this balance will hit directly at these two points, and the ramifications to employee morale need to be thought out in advance.
_________________
The Triple Constraint
When you are developing a product or executing a project, always keep in mind the
triple constraint
(
Figure 6-5
), which is explained simply by the following description:
Quality, features, and speed to market: You can pick any two.
Figure 6-5.
The
triple constraint
allows you to pick only two of the three primary product characteristics: features, speed to market, and quality
The classic triple constraint consists of cost, scope, and schedule. I personally prefer to look at speed, features, and quality.
Speed Plus Features
Our iWidget must be delivered to market by November 1 so that we can hit the Christmas shopping season. In order to compete in this tough market, we are going to pack the iWidget with ten new features.
The tight delivery date means less time to consider what the market wants and needs. There’s little time to put concepts in front of the potential consumer. The planning portion of the project gets cut short in a race to get to the build stage. The development team races to get it all done, but it will take as long as it takes to deliver the features. Another fact associated with the timeline is that we
will
have to sacrifice some desired features, and we
will
ship the product with known bugs. It is unavoidable because the engineering team has a drop-dead date to meet. The test phase is likely to get cut short as well, because of the time constraints. The resulting product will be delivered quickly and have lots of features with lower quality in terms of targeting the consumer, and in terms of robustness, it is likely to break often.