How To Get 11X Average Productivity In Product Development?
Posted by Robert Norton on
Here are Some Simple Ideas That Can Greatly Improve Productivity and at the Same Time Help Ensure Success of Every New Product or Release
Product management is more art than science and because I have run many product development groups simultaneously, with a very high launch success rate, I have been asked many times what are the key elements for success. This is not easy to answer, as there are hundreds of small things that make success, not just a few large ones. Although most examples are about software, the ideas apply to almost all product development efforts.
Due to my previous technical background as an engineer, software architect, and CTO, prior to becoming CEO, I have always been deeply involved in product development, no matter what title I held. As CEO, VP, or just software engineer, product development is often where the rubber hits the road and ultimately a company is made or broken by the amount of value the product delivers to its customers. In one position at a small company as "Vice President of Engineering" I wore the hats of Chief Architect, Engineering team manager (times 3), Product Manager, Product Designer, and Lead Programmer. Wearing all these hats can be both fun and difficult, but it takes the idea of the Mythical Man-Month to the extreme by cutting out the need for huge and inefficient communications overhead between many people. This can pay huge dividends in time to market and quality and is a great early-stage strategy, but for the long term, it is not for anyone who wants a life. Most often these functions must be spread over several individuals with strong working relationships.
In this scenario, these communications can happen instantly in your own head, instead of through many emails, meetings, and other documents oozing with selling efforts to convince everyone of something which is totally obvious to you because you have virtually all the information in one head. Sometimes, even if your way is not the absolute best, this amazing leap in efficiency makes it the best from an economic, speed, and competitive standpoint.
To learn more, click here
At this company, we had not two or three times the average development productivity, but ELEVEN times the average development productivity! Now that's a competitive advantage that impacts cost, speed, and no doubt also product quality.
Firstly, let me say I am a big believer in small development teams being far more efficient than large ones. Believe it or not, it is a fact that in most products (especially software) 3 to 6 perfect programmers can beat a team of 100 programmers at some corporate giant every single time. We could argue about why and waste many evenings and quite a few beers debating the impact from attitude, people quality, environment, motivation, lowered overhead, and just plain simple, but in the end, it really doesn't matter why -- It only matters that it is a fact. Each of these factors has an impact that is not additive, but multiplicative! So a small team is very key to high productivity. In fact, if you have a big product, the most bang for your buck will come from breaking people into small teams with very clearly defined goals that do not overlap at all and where interface documents are clearly defined and agreed to at the beginning.
Insist on Proper Design Time
One critical thing you need for amazing productivity is a development cycle that includes sufficient design time (and discipline). This is so critical, and exactly the opposite of what most programmers want to do. They want to code first and ask questions later. It's what they like to do - sit in front of a computer alone without anyone to challenge their ideas and thinking, and ultimately coordinate their work's merger with everyone else's work.
Although this is somewhat counterintuitive, allowing poor design discipline or time will double to triple your development costs and time and pretty much guarantee a poor product too. A good rule of thumb is 1/3 design, 1/3 coding, and 1/3 testing. The platform and language really do not matter that much, this ratio still applies.
Another rule of thumb is to pick a fixed time for development that is efficient, not place a number on the total desired feature list, then trim the release features to that cycle. Customers are only willing to accept a certain number of upgrades, usually no more than two per year so 6 months is a good timeframe for a product that is in rapid change. I would, of course, exclude websites and other more simple projects that allow rapid change and testing cycles.
Generally, the time available will be eaten up, plus more for unexpected problems and critical features that come up during the development phase. However, it is important to have a deadline that creates a sense of urgency. When this does not exist, engineers and designers will spend a lot more time than they should on making "perfect" details that cost four times as much and provide little value to a small subset of customers, and often no one but them can tell the difference. If Microsoft waited for Windows to be stable, it could have been at least 1995 before the 1987 version of Windows 1.0 was released as Windows 95.
Proper Customer Research Must Be Completed before Real Design Starts
With existing products that are in the field, research is much easier than with new products. You will generally have a broad array of customer requests and champion customers to interview. Therefore prioritization features more easily.
"Research" is a sticky issue with a new product and there is a talent to knowing what to listen to and what to ignore or put a lower priority on. It is critical that the research person understand the target customer's workflow process, biggest problems, and priorities.
Feature Review and the Dreaded Product Committee
Product committee meetings to review proposed top features are a necessary evil. For this to happen there must be a wild-ass guess ("WAG") cost estimate placed on each feature at the beginning to start the process. In most cases, this can be a person-day estimate for each feature to include all design, development, and testing of the feature. This translates into a cost that is important for everyone to see. People might request features thinking they are minor when they could cost $50,000 or more to implement. Given this knowledge, they will almost always choose to have 10 other features costing $5,000 instead. A feedback loop on cost and time is important here as should be considered an iterative process, not a one-time estimate, which each step getting closer to reality as development proceeds.
Place time limits on each release and advertise the limited window of opportunity to advocate for new product features in time to collect input. It is critical that top-level people attend this meeting from each department initially. They should understand this is their major opportunity to advocate for new features. This includes:
- Customer advocates (front line people who understand customer requirements)
- The head of engineering
- The head of QA
- Operations/customer support
- Chief Software Architect
- and YES ideally even the CEO or general manager
In my experience, the best chair for this meeting is the VP of Development and he/she must drive the process and keep it on a schedule, however, this can vary by personality and skillsets. There needs to be a start date for design, which is the end date for this feature review process.
Defining Objectives
Get everyone on the same page in terms of priorities and objectives for this product release. Everyone involved in development should understand the main objectives of every release and often will fit under some theme that is targeted at a particular group of customers or an industry where you are trying to build a competitive advantage.
Design is an iterative process. It can be broken down into 3 steps. Each individual step should cycle until a satisfactory solution is at hand. Do not ever cycle through all three, it must be done serially to be efficient and produce quality products.
-
Conceptual Design
-
Preliminary Design
-
Detailed Design
Conceptual Design is essentially whiteboarding the high-level objectives interactively with people in the room who can represent various constituencies. This should be a visual process with diagrams and finger-pointing to shortcut lots of words and to instantly be sure you are all talking about the same thing. Often words can be interpreted at multiple levels in the application and people will not be connecting. More than one meeting might be necessary and should continue until everyone can playback the same requirements and highest level priorities.
Preliminary design is when you let the engineers go away and come back with initial design specs to get it on paper. This is a rough draft, or a quick and dirty design to make sure everyone is on the same page. This must be limited to a couple of pages maximum per person or function. Going from oral to paper will always flush out issues and ideas. Guess what? Different people will come back with very different interpretations of the previous discussions. So this process saves big bucks down the line because these are text changes, not code changes that can have a wide impact. Everything needs to be iterative.
Detailed design is really flushing out the details of how everything will work. Each function or requirement may have several levels of design like conceptual, logical, physical, human interface, and field-level parameters allowed. This is a lot of work that will allow validation of the design with customers or customer advocates before coding starts. A-Spec Review and and "Sign off" on each spec is a necessary evil and the last step.
Other Functions That Need Attention
- Feature List Collection (ongoing process forever)
- Complaint/Bug list collection and review to set priorities and workarounds
- Engineering review (WAG) and possible mock-ups of known high priority items (starts while in system test of the previous release)
- Product Review Committee (Limited opportunity for advocates X times/year)
Rules to Live by:
No one, not even the CEO, should go around the "owner" of the development process who sets the schedule and control the features. A CEO might require a new feature for important business reasons, but the owner needs to integrate that into the development cycle and negotiate if and how that impacts the release date. At too near the release date this may be so disruptive as to not be worth it. Alternatively, other features might be removed to stay on schedule if they have not to be started.
Complete design of each component before you develop "one line of code" is critical. This is like pulling teeth but well worth it. You really need to insist that your programmers act like engineers, not hackers.
Change is always difficult and there will be lots of hemming and hawing, but to be a world-class player and have high productivity you need this type of system. Without it, you will spend your life-fighting fires and never achieve long term objectives and high productivity.
Bob Norton is a long-time Serial Entrepreneur and CEO with four exits that returned over $1 billion to investors. He has trained, coached and advised over 1,000 CEOs since 2002. And is Founder of The CEO Boot Camp™ and Entrepreneurship University™. Mr. Norton works with companies to triple their chances of success in launching new companies and products. And helps established companies scale faster using the six AirTight Management™ systems. And helps companies successfully raise capital.
What can we help you with today? Scaling, training, consulting, coaching?
Call (619) SCALE06 or (619) 722-5306 9am-6pm CT
Or Schedule a free 30-minute strategy session by clicking here.
Share this post
- 0 comments
- Tags: Expansion - Growth