When is time lost in a development project? Not where you think.
Your product development project is late again. Your boss said it needs to be done before it is shipped, but he needs it out ASAP. The sales team has already sold the first 5,000 and you’re going to miss the first ship date. Customers are calling about their orders. You’re so busy trying to get the product out, the last thing you have time to do is ask why the project is late.
When it’s all done, your boss asks you for a post-mortem. Your development team (quite large at this point) files into a room which is too small for them and the finger pointing begins. The engineers are convinced that the sourcing people were too slow. The sourcing people were waiting on a decision from finance. Finance says that the engineers were over budget. Everyone says they didn’t have enough time. But where was the time lost? Not there.
If you are one of the few people who have ever worked on a product development project that was delivered ahead of schedule, you may have an inkling what makes the difference between an on-time project and one which is late. The fact is the time is usually lost at the start of the project when the team is small, not at the end when everyone is involved.
I once asked a project manager to give me the schedule for the first phase of the project where the product was being defined. He said, “I don’t have one.”
“It’s all nebulous right now. Until the product is more defined, I don’t have anything to schedule.”
In fact, the development team on that project was spending weeks in their cubicles doing other things, not discussing the product, because there was no incentive for them to work on the project and no defined goals. Sure, they knew they needed a product specification, but how to get started?
Many people refer to this phase of the project as “the fuzzy front-end.” It’s about taking insights learned from your customers and turning them into opportunities and then concepts. And, like any other phase of the project, not only can it be scheduled, but it must be scheduled.
There are many ways to reach a product specification from insights, but here are some steps you can use to get there quickly:
- If you don’t have the insights about your customers’ needs, create them through customer observations. Technically this work should go on before the development project starts, but it can also be scheduled as part of the project.
- Rank your insights. Bring the team together to meet. Now that you have the insights, write each customer need on a Post-It note. Have the team group them by category, defining the categories as they go. Rank the groups by importance to the customer (not to you), because that’s where the greatest opportunity lies.
- Find opportunities for your business. For each ranked insight group, think about whether your competitors are serving that area. (Blue Ocean Strategy is a great way to do this.) Look for areas where your competitors are not. The insight groups with the highest customer need and the fewest competitors are your strongest opportunities.
- Develop concepts from these opportunities. Break the development team into groups and give them each a few hours to sketch up as many solutions as possible for each opportunity. (Don’t give them more than two to four hours. You will be surprised that less time will give you more ideas at a more conceptual level.)
- Prototype the concepts. Pick the least developed ideas with the greatest opportunities and assign these to teams to prototype each concepts in more detail. These prototypes should be on paper or made from foam core. Don’t let the teams spend days or weeks creating software, a piece of electronics, or milling something in the CNC machine. It’s not necessary. Use the simplest possible representation which gets the idea across.
- Place the prototypes in front of customers. It doesn’t take many – 5 or 6 people who would actually buy your product. Have them sign a non-disclosure agreement and show them the concept. Then stop talking and listen. Ask them what they would change, what they dislike, and what’s missing. They will tell you. Iterate the prototypes until you are sure you are solving that customer need you originally identified. Ideally, change the prototypes right in front of the customer.
At this point, your team should be able to develop a product specification. They have put the most time on the least developed concepts. They have done user validation. They know that they are the greatest business opportunity for your business. It’s time to write it down in a specification.
User testing doesn’t end here, it’s only the beginning. Run each iteration of the product or service by some customers who have the needs you’re solving for. Do it at the concept stage, at the specification phase, at the prototype stage, at the alpha stage, and finally do a beta test with them.
Most importantly, schedule the “fuzzy front end.” Put hard dates on each task above. Make sure your team knows that every day they are inactive on the project is another day the final product will be late. If you can keep your team focused now, you’ll end up with clear specifications that will make the later work of sourcing, finance, and engineering much easier to manage and more on schedule. … And perhaps you’ll have a project complete early too.