1 Do the Prep Work
Describe and validate the product strategy – the path to realise your vision – before you create your roadmap and decide how the strategy is best implemented. The following picture illustrates this approach.
As the picture above shows, I like to use my Vision Board to describe and validate the product strategy. The Vision Board captures the vision, the target group, the user and customer needs, the key features of the product, and the business goals plus key elements of the business model.
You can download my agile product roadmap, the GO roadmap, and my Vision Board from romanpichler.com/tools/ for free.
2 Tell a Convincing and Realistic Story
Your product roadmap should tell a coherent story about the likely growth of your product. Each release should build on the previous one and move you closer towards your vision. Your roadmap should be convincing and realistic: Don’t speculate or oversell your product. Be clear who your audience is: An internal roadmap talks to development, marketing, sales, service, and the other groups involved in making your product a success; and external one talks to existing and prospective customers.
3 Have the Courage to Say “No”
While you want to get...
[More]
Tags:
agile product roadmap
Posted at: 10:47 AM | 0 Comments | Add Comment | Permalink
Record Your Rationale
I just posted another axiom to the “97 Things” project called “Record your rationale”. The basic idea is that you should keep a record of why architectural decisions were made so that when someone asks, or when you’re thinking of changing your mind, it’s all there to remind you. This is a common problem, especially for architects who inherit someone else’s system: why this heck did they do THAT? Without a record of the rationale, inobvious solutions can seem like pure lunacy (or stupidity). I have actually caught myself voicing that sort of negative opinion out loud, right in the company of the very person that had done the implementation. Oops.
But I digress. I don’t want to spend this post rehashing what I wrote in the other site (if you’re interested, by all means go read it). I’d like to discuss how we’re recording our rationale at Sakonnet. First, let me post here a part of the original axiom that I cut out to reduce the number of details:
More formal approaches to this type of documentation involve using a standard template that includes the following information:
- The name (or brief description) of the decision...
[More]
Tags:
technical architecture
Posted at: 10:27 AM | Permalink
