Mission Research is a growing, startup company. We do not have an abundance of resources to be throwing at our products and for that reason we are always looking at ways to provide more value to our customers with fewer resources. I'd say we do very well given our constraints, but we can always do better.
Our products are the result of a series of well defined projects. We start out in an Envisioning stage where we define the concept and requirements of the project. Once the concept and requirements are "approved" the project enters the Planning stage. The Planning stage is where the project is defined and a schedule is created. This has historically been the toughest stage of our product cycles.
One of the areas we have been struggling with is figuring out the best way to get a feature or idea from conception to an appropriate level of definition so it can be turned over to our development team. It always seems to take longer than it should and just doesn't feel right. There is always a question about how detailed the functional specifications need to be. We occasionally fall into the trap of going too deep or getting hung up on details that could wait to be figured out. In some cases we actually get so hung up with implementation and technical details that we lose site of what our customers want. In my experience, this tends to happen when developers are brought into the process too early or are even responsible for the designs themselves. I'm not saying that developers can't design software; I just think that they're too close to the code and their thinking is limited by what they perceive as technical limitations.
So I've been thinking lately about setting up some smaller milestones within the Planning stage to keep us on track and guide the definition process. In my mind, the first pass at defining the functionality should be free from technical limitations. Ideally, lock the product manager and designer in the room with a sample of customers and don't let them out until the customers have written a check for the idea based entirely on the high-level specification the designer has created for them. Now that will probably never happen, but the idea is to come up with something that totally meets the needs of the customer without someone standing over their shoulder telling them that what they designed is not possible. I'm not saying the initial design process is void of any logic, it has to make sense and be consistent across the design, but it shouldn't be constrained by what a "technical" person thinks is doable. Allow your designers to think outside the box. Because locking up your customers is not very feasible, what else can be done to create the same environment?
What if we made one of the first milestones in the Planning stage a presentation to the customer? Or if that isn't possible, your customer advocates-- sales, customer support and customer experience. This milestone would ideally occur before there is interaction with the development team. Now this may not be possible depending on your project, but it would be a good litmus test. If your designers are spending time with development before the Presentation Milestone then it should raise a red flag. In our company, a presentation would include some screenshots, a list of capabilities and examples of how the new features will be used. It should be detailed enough to give the audience a good overview. Each group should be evaluating the design from their areas of expertise. Can the support team support it? Can sales sell it? Does the design make sense and does it address the customer need? The Presentation Milestone is crossed when the design addresses all the holes revealed in the presentation.
Whether or not we actually inject that milestone into our product cycle or not, I think it's what the designers should be thinking in the first pass of designing the software. Another purpose of the milestone is to get the designers thinking across the entire functionality set before diving too deeply into the details of a specific function, going wide before going deep. It's very possible that a feature may be passed on once the full scope of the feature set is defined. Hopefully some of that wasted time can be avoided and the design process can be shortened.
Once that milestone is crossed, the designers are free to meet with development to figure out how to implement the design and how long it will take. Obviously some things won't be feasible for technical reasons, but the point is that the design should represent the ideal solution and that's the best place to start in my opinion.