Why Your Roadmap Should Be Flexible
向互联网表示：饭已吃完，澡已洗完！幸福就是这么简单！工作了一周，说是幸福，[大哥,你是在和我扯犊子吗？]仔细回想本周的工作，主要还是在产品开发阶段的实时追踪及需求支持。整天跟着开发哥哥、测试姐姐转，着实是忙得热火朝天，乐此不疲。其实，回顾整个产品生命周期，每一个产品对应着相应的产品路线图（Product Roadmap）,互联网产品路线图能从一个长期的过程来规范/锁定产品的发展路径，把握好产品的前进方向。下面大家一起分享关于 Product Roadmap的思考与认识。
Defination of Product Roadmap
A technology roadmap is a plan that matches short-term and long-term goals with specific technology solutions to help meet those goals. It is a plan that applies to a new product or process, or to anemerging technology. Developing a roadmap has three major uses. It helps reach a consensus about a set of needs and the technologies required to satisfy those needs; it provides a mechanism to help forecast technology developments and it provides a framework to help plan and coordinate technology developments.
The existence of product managers in the product software industry indicates that software is becoming more commercialized as a standard product. This manager is responsible over the whole line of software requirement management, defining of products and their releases and this with all internal and external stakeholders involved. In this context, product roadmapping can be placed to aid software product managers inplanning and placing their products with the use of scientific and technological resources. For managing and using the technological resources technology planning can be used.
正文
I talk to a shocking number of Product Managers（PM） on a regular basis who are exasperated at their company’s approach to roadmapping.
Some companies refuse outright to have a roadmap, instead opting to put to paper only what they can commit to in the next few sprints–ie. a release plan or project plan. These poor product managers spend most of their time either firefighting or building whatever tickles the fancy of their CEO/noisy sales team/eager developers, etc. They constantly struggle to make the case for building anything with long term value.
Others take the opposite approach, and insist on having a structured, committed roadmap glorified Gantt charttoguide the team across every obstacle and iteration in the next few quarters (or years!). In these cases, the Product Manager ends up acting as a project manager. Realistically, it means adding all sorts of buffer and hoping for the best as each month crunches by, all while constantly having to make excuses for the roadmap’s inevitable changes in scope and time.
Product Roadmap
Why bother with a roadmap?
Many companies do realize the importance of creating a product roadmap. An effective roadmap is a carefully designed document that communicates the product vision and the areas of focus that’ll be tackled to get there. Its purpose is to show the development, sales, marketing, and other internal teams in the company the vision for the future of a specific product or product line. It will set broad goals and provide the steps necessary to achieve them.
According to anarticle in Pragmatic Marketing Magazine,“As your company grows, different departments will be involved in executing different elements of product delivery (e.g., marketing, distribution, development). A product roadmap keeps everyone aligned by defining a common vision for the company’s direction.”
The many benefits associated with a product roadmap are what make them essential. With a good roadmapping process in place, and a well-designed product roadmap, every company department, from sales to development, will work better. It provides the product team with a valuable artifact for constructive conversation, both at the inception of the roadmap and in follow on conversations as each month passes and the roadmap is reviewed. The very nature of the roadmap should outline the product vision effectively enough to allow teams to work with relative autonomy, and ensures that a cohesive, valuable product is being built.
Career roadmap
Importance of flexible roadmapping
Flexibility in Time
Product release dates can change, and those ‘set’ months or quarters in advance certainly will. Instead of setting exact dates as releases, set a series of ‘time horizons’ such as ‘Current’, ‘Near Term’, and ‘Future’, or at the most granular, quarters for the upcoming half year, half years for the following couple of years, and if your roadmap extends that far, granularity at the year level.
This approach allows you to have flexibility to switch around projects in projected time horizons, without having to rejig your entire roadmap. Each time you have to realign and re-communicate a new roadmap, you need to instill understanding and buy-in for the latest changes – this will often kick off drawn-out discussions about, for example, the order of Project X and Project Y, even though both are realistically not going to get touched until the following year anyway (by which time, a lot could have changed, so the conversation was for nothing!). Over the course of months, the team can change, technology can change, and development can have unanticipated challenges. Setting dates based on time horizons rather than actual release dates helps keep the focus on the wider picture, delivering towards the product vision.
Flexibility in Scope
The reality is, some companies have to deliver to dates. There’s a signed off project, or an important conference coming up, or a seasonal marker – whatever it is, it shouldn’t prevent your company from being able to work to a flexible roadmap.
As the old adage goes: “Quality. Speed. Price. Pick two.”
In the case of signed off projects, with a set scope and a set time, there’s not much you can do besides hunker down and deliver it. For this, you will need a project plan and a detailed understanding of what needs to happen at each stage to ensure nothing slips. But this isn’t a product roadmap, or even part of the product management process – this is project management and requires a project manager hat (I speak to a lot of product managers who find themselves stuck in this situation, simply delivering on projects instead of building and iterating based on the product vision). As the old adage goes: “Quality. Speed. Price. Pick two.” If time, scope or quality starts to slip, be prepared to pull in extra resources, even if it means taking them off other areas of the roadmap… another reason to build in flexibility in that roadmap.
For projects with a set time, the only way to even estimate a future delivery date, without spending tons of effort in sizing, scoping, and planning a detailed project plan for it, is to remain flexible in scope. Your roadmap shouldn’t be made up of detailed features outlining exactly what should be delivered. By the time you get to the point of starting on that feature, the entire product or market may have changed around it, meaning all that spec’ing effort was for nothing. Instead, outline ‘areas of focus’ and provide details of theproblem you intend to solveas part of that deliverable. For example, instead of promising Facebook Connect in Q4, outline it as ‘Social Connect’ – by Q4, it might turn out that LinkedIn is more important to the business, or MySpace made a comeback. You’re still solving the same problem, allowing people to connect via the social networks they use the most, but you’re not stuck breaking old promises.
Roadmap
Reviewing your Product Roadmap
Share your roadmap with other stakeholders to get constructive feedback
Naturally, the further out a potential area of focus or deliverable is on the roadmap, the more flexible on time and scope you’ll need to be.
If you review your roadmap on a monthly basis, you can add extra granularity to the areas that are more impending, shift around deliverables based on what you’ve learned about your team, the technology and the market in the last month or so, and deliver a roadmap that’s subtly different, but not a massive change from what the team was already bought into. With a flexible roadmap, you’ll stop that trend of simply shifting all of the items to the right by 1 month in order to adjust for whatever new projects or slowdowns cropped up in the last month. You’ll have a clean, concise, and useful roadmap as an artifact for discussions on what really matters – delivering on the product vision.
友情提示：原文来自 MindTheProduct
原创声明：本文章的最终解释权归产品小王所有，如需转载，请注明文章出处！谢谢...
网友评论