How Detailed Should Your Startup's Product Road Map Be? (Infographic) If your plans are too detailed for your team's size, you're wasting everyone's time.
By Andrew Cohen Edited by Dan Bova
Opinions expressed by Entrepreneur contributors are their own.
I spend a lot of time thinking about Brainscape's long-term product vision. Sometimes, I'll lie awake until the wee hours of the morning, visualizing some new feature suite that is so advanced we're probably a full year or even two away from developing it.
Related: 9 Essential Tools for Agile Product Development Teams
My enthusiasm for these visions is often so great that I am tempted to draw up wireframes, call a design meeting for the next morning and present my new mockups as the potential future for our product architecture.
But then I snap out of it. You see, there is a delicate balance between the size of your engineering team and the level of detail with which you should be pre-planning your product's long-term development.
Take the middle road.
If your plans are too detailed for your team's size, you're wasting everyone's time, since plans will undoubtedly change by the time you're actually ready to implement them. If they're not detailed enough, your team will lack a cohesive vision, and as leader you will appear weak.
When your early-stage team has just one engineer, he or she should probably not create any detailed low-level plans any longer than one or two weeks out, since things change so frequently. And longer-horizon tasks should be forecast only to the minimum level of detail necessary to predict ballpark development time frames or potential conflicts.
A one-man (or woman) development team should thus have a pretty vague long-term product road map. At the same time, that developer should be focusing on a minimum viable product based on Lean Startup principles. In short: In the early stages, you need to fall in love with the problem, not the solution.
Of course, even the earliest-stage team can and should have product visions that are much bigger than one week away! After all, you are pitching a product that is going to "change the world," right? But those visions should be articulated in a gradually decreasing level of detail as the product horizon gets longer.
Related: The Most Important Thing You Must Do as a Hardware Startup
The most immediate short-term details should ideally be flushed out on a weekly basis, based on data: What have customers been saying? What have you learned from survey subjects in your usability tests? What have you learned from your web/mobile analytics? What great new advice have you gotten from your advisors?
And what new engineering challenges have cropped up that you hadn't expected? All of these things can and should cause you to constantly tweak your short- and long-term plans, as needed.
Below is a rough guideline for the level of detail you should plan for your product road map, based on team size. Of course, true optimal numbers may be slightly different, but you get the idea:
A few quick definitions may be useful:
- Detailed tasks -- The low-level project management spreadsheet, where nitty-gritty tasks are outlined, explained in detail and assigned to engineers on the team. This list is ideally written, or re-visited, at least every week (or in some cases, every day).
- Wireframes/spec -- This is the general picture of how each upcoming screen/feature will look and work. This spec is ideally developed in a design meeting led by a lead UX designer with a vision for brand consistency, and should incorporate feedback from key users and stakeholders. It wouldn't make sense to develop these detailed wireframes too far in advance, since the functional spec may change in the interim.
- Rough backlog -- This is the shared wish-list where you keep a log of every potential feature or initiative that has been suggested by a team member or user -- as a simple line item for each. Every time the product visionary (ideally the CEO) is ready to decide which feature the lead UX designer should design next, he or she should examine the tech backlog and choose the feature that is the highest priority based on expected impact on revenues, conversions or user experience. These decisions are often a great topic for a monthly/quarterly, strategic all-hands meeting.
Obviously the specific cutoff points for each level of detail depend on many factors related to your team and product. The key take-away with these guidelines is that your necessary level of product planning grows in line with the size of your team and product complexity.
If you're Facebook, Microsoft or NASA (with massive engineering teams and billions of dollars), you've got to plan your next mega-feature years in advance, while your feature backlog horizons may be on the magnitude of half-decades.
If you're two guys in a garage, however, you'll want to limit your detailed plans to flexible weekly milestones, or else some other competitor is going to implemen your concept better and do it faster.
