How to Build Consistently Successful Products
A Guide for Prospective Entrepreneurs
By Robert Lamm
Getting It Right Every Time
It's the collaborative process that counts
A video person tells a computer person: "I hate the way I have to manually frambellitize my footage! There should be some way to do this with a computer." The computer person asks: "Exactly what do you need it to do?" After a bit of back and forth, the two of them come up with a product design and start a company to build it. This is a very sound way to build a product - and to start an enterprise - two complementary partners each bring critical expertise to the table: The video person (aka Marketing) brings domain knowledge of the problem that needs to be solved and the computer person (aka Engineering) brings the necessary technical expertise to build the solution. With the addition of money (a financial guy to raise startup capital and a sales guy to generate revenue), they now have a viable entity that hopefully will grow up to become the next Avid.
So how are new products really developed? It's an old cliché, but the most important thing to remember is that it's the customer's view of the problem that counts. Much of the success of companies like Avid stem from the fact that their products are so customer-centric that they even renamed computer-related elements like files and windows as 'clips' and 'bins'. The idea is that even a casual passer-by should be able to recognize the process he's doing in the product's user-interface and operate the system intuitively. If that's the case, his next question is likely to be 'how can I buy this?'. Competing products that have to be explained before the user can figure out what they do never get to this step.
The second important point to remember is that it's got to be buildable! Many products founder because they're too ambitious for the time and resources available. It's often better to build a very basic product that does one thing well than an ambitious product that tries to satisfy too many mandates and never gets finished. This is where Engineering needs to speak up and provide real-world feedback on what's really feasible: Without this, Marketing will promote a product you'll never be able to deliver.
Third, it's got to be commercially viable. Many novices fail to do the proper market research to make sure there really are enough potential customers for their product. This is especially true in the case of high-end video gear: People from outside the business consistently overestimate the size of the professional film/video production industry because it's so visible. To this one has to add the fact that it's a finicky market where the best product gets all the sales and everything else sucks wind.
Finally, it's important to remember that successful product development is always a team effort. It's not just the various expertises that each member brings to the project, it's the reality-check they provide on each other that keeps mistakes and false assumptions from screwing the product up.
Real-World Product Development
Putting the team together.
If you're an engineer who wants to build a product for the video industry, go out and find some representative customers and listen to them. Even better, get someone with experience selling to this market and who knows it from a vendor's point of view. You're going to need someone who knows how to build a distribution channel, market the product effectively and motivate sales. For that he needs to be familiar with the field and have some personal credibility in the marketplace. Hiring an MBA off the street isn't enough: what you want is the industry-specific knowledge and connections that accumulate over years.
A going enterprise that wants to add a new product will usually first appoint a Product Manager to lead the development team. This is usually a marketing person, and their new job is to be the product's advocate, custodian of the product vision and overall expert on everything related to the product. Good product managers are hard to find because their expertise has to span so many areas, but many of the best ones are former users or salesmen who then picked up the marketing aspects of the job. Some companies appoint engineers as Product Managers, assuming that they'll bring some technical depth, and this is almost always a mistake: Without a background as a user or vendor, they aren't able to fulfil their primary mission as user-advocate and reality-check.
The toughest part of being a Product Manager is balancing all the tradeoffs in the face of great uncertainty: Lots of decisions need to be made before you really have all the information you need - and only hindsight is 20/20.
The next person who usually comes on board is an Engineering person to help figure out how to build the product: The title may vary, but 'Project Manager' is most common. Again, prior experience makes a big difference. These two people - the Product Manager and the Project Manager - form the core of the development effort, although they usually interface with Sales and Upper Management on marketing and business issues.
Reasearch Is The Most Important Step
Your team has this great product idea - maybe you even have a potential customer who wants to buy it. Resist the temptation to start building it or even to do any design work and spend some time doing some market research:
Whatever your product hopes to do, go out and study how people are doing it now. Visit as many potential customers as you can to get the best possible sample. It's not enough to know every step the users take, you also want to understand why. Inquire about everything possible such as exactly what processes they follow to do different things, the specific functions they use, how often they use them, the ones they feel are essential, how other people in the field do the same thing, the signals they need, the equipment they interface with, the data formats they use, other products they may be considering, how much they paid for comparable equipment, where they usually buy it, the publications they read, what they think your new product should do, the functions it should have, their dream system, etc.
Take notes about everything you learn, diagram the users' entire workflow out, study how they arrange their workspace and circulate all this info among the development team. Having trouble summarizing all this information in a complete way? Perhaps your product's mandate is too broad and you should narrow its definition to a mappable task. With a curious mind and the time to do this 'due diligence', you'll get lots of ideas, catch lots of false assumptions and focus your product on specific marketable customer needs.
Check out competitive/comparable products. This isn't just a matter of comparing feature lists and specs - it's more like a house inspection: Bring a user along to for guidance and get a very complete demonstration. If you can, buy a copy. Or at least spend lots of time with with each product to explore every nook and cranny to look for strengths and weaknesses. Ask everyone you can find about what they like and dislike about these products.
Now is the time to do all this - before you've spent valuable time and money on hard code.
Research is the cheapest part of the design process, but in many respects the most important: What you learn here is going to drive your entire product design and marketing strategy. Without it, you'll be sailing blindly into the marketplace and could easily make a serious mistake that dooms the product. I'm sure it's out of ignorance and impatience more than anything else, but this critical design step is the one that novices are most likely to skimp on. The result is almost always that the product has to be reworked later on - at great cost and loss of time - if it isn't abandoned altogether.
Every so often, you'll meet product advocates who pitch their design as a 'new paradigm': This almost always means that the developer hasn't bothered researching the users' workflow because he intends to impose his own. Be very careful about jumping on board with any of these concepts because users usually have good reasons for doing things the way they do. Adopt only those 'new paradigms' that clearly generate enthusiasm with users in a position to buy them.
When all your research is done, you should have a pretty good idea of what you want to build and who your market is going to be. Write it all up in a 'Business Case' that describes the fundamental economics of the project: What the product will consist of, how many people are likely to buy it, some estimates about how much it will cost to create/market and how much money you hope to make. Be as specific as possible: Vague 'billion-dollar digital content creation markets' (a common phrase back in the good old dot.com days) won't cut the mustard in today's post-Enron environment. You'll need to talk about specific customers like 'film compositors who have to spend a lot of time manually masking out trees and other foreground elements' or 'game developers who need a tool with which to stream 3D games over the Internet' and coherently explain why these people will buy the your product over all the others. It doesn't have to be long or complicated - I've seen business cases written on cocktail napkins. The important thing here is that you've done the proper research and have verified that this is really going to fly.
Product Design: Focus On The User Experience
The UI is the soul of the product
Now that you've researched the user's needs and narrowed them down into specific tasks, go ahead and design the product. In most cases, the best place to start is with the User-Interface: It embodies the entire personality and power of the product - and it's part the customer sees and buys. The functionality you put into the UI will then drive the underlying product architecture and engineering. Give it plenty of thought because it's very hard to change, especially once you've got versions of it in the marketplace.
Three Golden Rules of UI Design:
Keep it simple. Don't overcomplicate it with lots of windows, panels and options that confuse the user. If the process is inherently complex, present a simplified version that the user can drill down from into futher detail if he needs to.
Use familiar terminology: This goes beyond just labeling - it also includes organizing the UI in a way that will seem logical to the user.
Make simple, repetitive tasks quick and easy to do: Ideally, common tasks should take a single mouse-click or keystroke. Consider putting them on a toolbar. Or fill in default values on settings panels, use Media-Cleaner-type templates to fill in large numbers of variables with a single click, or even context-sensitive fill-ins. But test these with users to make sure they help rather than confuse.
A good way to start a UI design is to mimic the customer's manual process on the computer screen. This was the way the Avid Media Composer was designed and it prevented them from having the big functionality gaps that some of their competitors suffered from.
I can't overstress the importance of running your designs past users for a reality-check. Especially when it comes to technical improvements that might affect the workflow. At Avid, the design team even wrote up a complete prototype instruction manual. This methodical, user-centric design plan paid many dividends: Almost 15 years later, Avid's original user-interface remains essentially unchanged - and is still acknowledged as the best.
One company I worked for built an HTML simulation of the product that prospective users could play with: I thought that worked out very well: Design changes could be executed in minutes and the simulation was available to everyone at the company, so even the programmers could play with it to get some idea of how the product was supposed to end up working.
The other big UI design issue is deciding which features to implement. Here are a couple of rules I use:
Always solve a very specific problem for a specific customer. The ideal situation is to have some real customers to use as guinea pigs. They'll warn you if your product is straying away from usability or suffers from any critical functionality gaps.
Leave the non-essential functions for later. Put in just enough functionality to do the job and no more. Keeping the application simple will allow you to get the basic design and technology down pat and ship a 1.0 version as quickly as possible. The frills and options can be added after the first version has been released and you've gotten some real-market feedback about which ones to prioritize. Don't forget that everyone admires Ferraris but that they somehow always end up buying Fords.
Add options strategically: I'm getting a little bit ahead of myself, but when you're adding new features for Version 2, don't listen to the customers too much (!): They'll have you adding coffeemakers to their editing stations. The people you really want to listen to are the ones who aren't buying your product because it's missing something. New features should always be added with an eye on how many additional purchases they'll motivate. Always ask prospects how much they'd be willing to pay for each option. It'll weed out the wish-ware from the stuff they're really serious about.
Make improvements prove themselves. Just because it's possible to push a pea up a mountain with your nose doesn't necessarily mean that that's the best way to get it there. Make sure all suggested improvements actually make things better before adopting them. Not sure? You should know my answer by now: run it by a user...
Test the technology. Does your product use some new whiz-bang algorithm? Build a very simple test platform (a command-line version will do) that you can run some real-world data through to make sure it works as expected. Especially if it comes from of a non-commercial environment like a research lab or university: Technology from these sources will not have commercial-grade robustness and may not work well outside of controlled lab conditions. Don't finalize the product design until you're absolutely sure the technology will support the workflow you've designed without any special tweaks, pre-processing steps, etc. I've worked at places where the technology proved so inadequate to the task it was originally intended for that we had to abandon the original product idea and search for other uses for it. This is a miserable position to be in...
Prepare for the unexpected. Leave some flexibility in the UI design for functionality that you may not have thought of. Who knows, there might be some hot new HD 3D web streaming functionality that you'll want to shoehorn in next year when that technology explodes onto the scene. The easiest way to do this is to make your software design open to plug-ins at various levels. If you hope to have third-party developers, keep the SDK and documentation simple because many of them might be users/part-time programmers with limited programming skills. P.S.: Your application will need to be commercially successful before you'll get much interest from third-party developers, so don't invest too much effort into third-party plug-in support right out of the gate.
Run your design ideas past the engineering and sales folks. Not just to make sure it's buildable and sellable, but also so they get some idea of what you're planning and can start thinking about how to implement it and sell it.
Don't let the customer's point of view get lost. I know this is an engineering publication, so I'm putting this in on purpose: Engineers tend to see the product as a collection of data structures and mathematical functions. Left to their own devices, they'll create software that exposes the algorithms with scientific purity and provides controls for every parameter and register. If you let them, they'll even invent a scripting language so the user can write code just like a computer programmer!
But users tend to think in terms of what they're trying to do: Make the special-effects flames look hotter or animated dinosaurs more ferocious. Instead of scientific parameters, they want simple controls for things like flame amplitudes and the amount of anger in the dinosaur's face.
Make sure that Engineering understands this - better yet, bring engineers on some of your research trips and to trade shows so they have a chance to interact with users and get a feeling for how they think. Then they'll understand the need to build the application around the user instead of the algorithm.
The business people in your operation will also have crazy ideas like combining your video editor with a coffeemaker because the venture firm that's funding you is also behind a failing coffeemaker product and would like to try saving it from oblivion. It's hard to say 'no' to the folks with the money, but they're more likely to listen if you have some market research to back up your point of view.
Don't allow the perfect to kill the good: An imperfect product that gets you some quick revenue and market feedback on improvements is better than a perfect product that never gets released. Ship products that are useful even if they have shortcomings as long as they aren't fatal. Be honest about them to the users - the ones that care will wait for Version 2. It's the nasty surprises you don't warn customers about that will make them mad and cause you grief.
Horse trading your way to Version 1.0
Small enterprises rarely document their products well and it almost always comes back to bite them later on. Without documentation, your development team members will have trouble coordinating their efforts and critical knowledge about how the the product works will be lost every time an engineer leaves. Most importantly, documenting the product's design forces you to think about it and prevents you from starting the implementation before everything has been properly thought out. These are the common design documents most companies generate:
Functional Specification: The design of the product from the user's point of view. A button-by-button description of the UI, a list of all the specifications and a qualitative description of all significant performance issues. ("Pressing the stop button should stop the video immediately.") How much detail? Enough so the engineers know exactly what you want. If in doubt, describe it. Otherwise they're gonna guess and you're gonna be sorry!
After you're finished, call it a first draft and pass it around for feedback. Assuming no big objections, the engineering department will study it and respond with the following two documents:
Engineering Specification: The design of the product from an engineers' point of view. Things like databases, processes and even some variables will be defined, as well as application architecture and a description of all functional modules. As the Engineering department discusses all this stuff, they'll call in the author of the Functional Spec (usually the Product Manager) to discuss tradeoffs that might be necessary to make implementation easier/possible. This process can go back and forth several times as the Functional Spec is adjusted to make the engineering implementation easier and the Engineering Spec is adjusted to accommodate mission-critical functionality. Passions can get inflamed and discussions can get very hot and heavy, but the process will be a lot smoother if you've been running your ideas past Engineering for informal feedback while writing the Functional Spec.
Project Schedule: Each portion of the project will be assigned to someone along with a time allotment to complete it. Again, tradeoffs are usually made in order to have the product completed within budget and in time for the Big Trade Show.
Be sure the schedule is realistic - it needs to account for holidays, sick days, and even a bit of developer turnover! A more insidious problem is when developers under-estimate the time needed to complete tasks. Usually this happens because they didn't really examine the problem closely enough, they misunderstood what you had in mind, the design was too vague to really estimate properly, or they're afraid to give you bad news and hope to magically pull the code out of a hat later on. Push back on estimates that make you uncomfortable - or you'll find your own back pushed against a wall later on. If a task can't really be estimated, assign it the maximum time you're willing to invest in its development - and be willing to abandon it if it runs over.
The project schedule usually includes a Gantt chart: a diagram that shows all the subtasks neccessary to complete the project. Examine it carefully, especially for dependencies: Those are tasks that can't be completed until something else is done first. The more of these you have, the more likely a small screwup will set back the entire project.
The negotiations are over. Compromises have been made. Is the product still useful to somebody? Now is the time to finish off the Business Case. Go back and update it to reflect the final product design and the new development cost information. This is also the time to start fleshing out sales and marketing costs.
Once all of these documents have passed muster and are officially approved, freeze them. This is what you're going to build. Keep all changes to a minimum and document them in the form of addendums to the original documents. Engineering updates as you discover bugs and problems that need a re-work should be posted every week or so after everyone involved has had a chance to think about the necessary fixes and sign off on them. Complete rewrites of the basic three documents above should not occur until each software version has been completed and you've had a chance to see how the market reacts to it.
Building The Product
Hoping we all meet at the same place
Finally we're finally ready to build something! With all our preparatory groundwork, let's hope we can do this with a minimum of dead ends, throwaway code, etc.
Some simple rules:
Try to get programmers, engineers and other developers with prior experience with similar products. They'll have some feeling for what you're trying to build and make fewer dumb mistakes.
Keep technologists on the periphery. PhD's, academic professors and research scientists spend their careers studying a particular technology and will be advocates for it. Product developers, on the other hand, need to be experts on solving a particular type of problem and able to adopt and drop technologies as they see fit. Never forget that your product is not here to promote a technology but to solve a problem.
Minimize dependencies. Divide the project up into independent modules that can be built and tested separately. This will not only prevent one person missing a deadline from setting the entire project back, it will also make everyone else more productive! Why? When independent modules can be rebuilt and tested in a few seconds, the developer never loses their train of thought. But when complicated, inter-related modules take 15 minutes or more to compile, the developer will go get a cup of coffee or visit a friend down the hall - and may not return and get back to work until an hour later...
Make sure the people doing the work sign off on the schedule. A schedule that the programmers can't meet is worse than none at all. Simplifying the product and removing features is a more effective way of reducing completion time than adding workers because there's always a confusion factor as you add people to a development team. Leave some slack in the schedule for unforeseen problems - they always occur. And have a (secret) backup plan to abandon some features if the schedule starts to slip. (Keep it secret or it'll be the unofficial official plan.)
Avoid one-man teams. Two-man teams are more productive because they egg each other on a little bit. Try to put complementary people together, such as people with dissimilar backgrounds or different skill levels so they can learn from/mentor each other. But the main reason for having two-man teams is to have someone to pick up and run with the ball in case one teammate is run over by a bus.
Discourage programmers (or anyone else) from working at home: Communication is enhanced when everyone is in the same location, preferably on the same floor. Cubicles are better than offices and desks with no dividers are best of all. You won't believe how many potentially serious problems are averted because somebody turned to his desk neighbor and asked a quick question. Put distance between them and they start having to write memos...
Keep your documentation up to date. You can buy special documentation packages such as Clear-Case, but my personal preference is to have each development group write up Word documentation and appoint a Documentation Coordinator to publish it on an Engineering web site. That way it's easy for everybody to refer to. Make it easy for the engineers to update their documents - if it falls behind it'll be useless. But make sure everybody affected by a design change is OK with it before you make it official. Back everything up regularly...
Complete a build every week or so. Compile all available modules into a prototype program. This will allow you to flag compatibility problems in their early stages and force people to fix bugs before they get too embedded in the code. As the application grows more complete, compile it every day.
Hire people to bang on the code. It's called Quality Control (QC) and the best people to get for this are folks with a user-background because they'll have a better idea of what performance levels are really needed. At first they'll test very basic stuff: Do the software modules run without crashing, input the data properly, etc. They'll gradually work their way up to testing the features, running it on different platforms and evaluating usability. A reasonable number of testers is one for every two or three programmers and they should be physically close to the programming team so they can interact with the programmers easily (you don't want them having to write memos about every bug they find) and the programmers can sound them out when they have design questions.
Novices almost always underestimate the time it takes to QC and debug a product. In extreme cases it can take longer to work out the bugs than to write the entire application! (I've seen this happen several times.) This is especially likely to be the case when modules come from third parties and you don't have full control over all the components.
Maintain a public schedule. Post the Gantt chart on a wall large enough so each task can be identified along with the developers assigned to it. Have the developers mark off the tasks as they complete them so they can survey the whole schedule and get some idea of how they're contributing to the project. On large projects, where individual contributions are easily lost, this will keep morale up.
Have weekly engineering status meetings. Check out the latest build and have everybody say a few words on how they're coming along with their part of the project. That way people can can coordinate with each other and you'll get a feeling for where problem areas are developing. Keep an eye out for people who might be falling behind and those who might be available to pick up some of the slack.
Make a point of hanging out with the troops: Go out to eat lunch with them, stop by their desks every so often to socialize, etc. (Don't overlook anybody - people will read all sorts of paranoid meanings into it.) People will be a lot more candid and tell you much more about problems they see one-on-one than they will in official meetings once they get to know you and trust you.
Invite users in to check the progress. As bits and pieces begin to fall into place, invite occasional users to come and look at the product in the making. The main idea is to make sure you aren't misimplementing something critical, but they'll often suggest improvements too. But be very resistant to adopting any new features that require extra work because it'll throw off the entire development schedule. Unless it's absolutely necessary, put all proposed enhancements on the suggested-feature-list for Version 2.
When the entire application is done and reasonably stable, call it the 'Alpha' version and invite users to come play with it at your facility. If they have real work they'd like to do, this is an ideal test (and fodder for future marketing propaganda). Assign someone from QC to babysit and see how things work out. This is probably your first chance to test the instructions: Give them to a user who hasn't seen the product before and see how they fare. Do this all this at your facility so you can observe and call the programmers into the room if the whole thing comes to a crashing halt.
When you feel the product is really ready, call it the 'Beta' version and give some copies out to local users to try out on their own. Here you're really testing for issues of portability and compatibility. If your product turns out to to only run on hardware configurations you have in your lab, you may have to go back and do substantial rework or come up with compatibility charts to guide users. This is also your last chance to make sure the installer and instructions are really foolproof. I know, they'll just invent a better fool, but the idea is to do everything possible to minimize tech-support calls when the application is released. The last thing you want is for every single user to call the technical support line when they try to install the program! (This really happened to a company I won't name when they deleted an unused but inventoried file from their final CD at the last minute. It caused the installer to automatically throw up an error message that people didn't know they could click through.)
If all goes well, you'll have a release version of the product and documentation that you can send out for duplication. Just make sure everything has been tested and then don't do anything to change it.
In The Meantime...
Product Documentation and Marketing Plan
Did I mention that while the programmers are busy building the product, you should be busy writing the instructions, designing the packaging and preparing the marketing materials? The Functional Spec can be used as a template for the instruction manual. And the workflows you did during your initial researches and product layouts can be expanded into tutorials.
But by now most of your time will probably be spent with coming up with a Marketing Plan. But that's another article...
Bob Lamm has 25 years of experience in the field of video product development, marketing and sales. He can be reached at 617-277-4317, firstname.lastname@example.org.
(I'd like to extend a special thanks to Professor Colin Godfrey at the University of Massachusetts/Boston for inviting me to rant at his class (twice!) - which inspired this article.)
Copyright (c) 2002 Robert Lamm