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 long-term development. If your plans are too detailed for your team’s size, then 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, then your team will lack a cohesive vision, and you will appear weak as their leader.
The graph to the right shows a very rough estimation of the ideal level of detail of your product roadmap. (By “Weeks of detailed development plans”, I mean the number of weeks for which extremely targeted tasks are assigned to to developers, for low-level things like “Create new database element for X” or “Apply CSS styling to buttons” or whatever.) Note that the graph suggests that an early-stage team of only one engineer should not create detailed low-level plans any longer than 1 week out, since things change so frequently. Longer-horizon tasks should only be forecast to the minimum level of detail that is necessary to estimate ballpark development time frames or potential conflicts.
Of course, even the earliest-stage team can/should have product visions that are much bigger than 1 week! (Your vision is for your product to change the world, after all.) But those visions should be articulated in a gradually decreasing level of detail as the product horizon gets longer. And no matter what the level of detail at each product horizon, you should be constantly re-visiting the detailed plans every week, based on data: What have customers been saying? What have you learned from guinea pigs in your usability tests? What have you learned from your web/mobile analytics? What great new advice have you gotten from your advisors? What new engineering challenges have cropped up that you hadn’t expected before? 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 your Product Road Map, based on team size. Of course, true optimal numbers may be slightly different, but you’ll get the idea:
And a few quick definitions:
- 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 is ideally developed or re-visited at least every week (or in some cases every day).
- Wireframes / Spec – 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. (Note: After the conceptual wireframes emerge from each initial feature design meeting, the Designer should still be constantly tweaking the wireframes based on ongoing usability tests of the non-operational wireframes themselves.)
- Rough Backlog – 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. Each time the product visionary (ideally the CEO) is ready to decide which feature the Lead UX Designer should design next, s/he should examine the tech backlog, and choose the feature that is the highest priority based on expected impact on revenues, conversions, or user experience.
The key take-away here 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, you’ve gotta plan your next mega-feature years in advance, and your feature backlog horizons may be on the magnitude of half-decades. If you’re two guys in a garage, you’ve gotta keep your detailed plans limited to flexible weekly milestones, or else some other competitor is gonna do more faster.