The Art of Building a Roadmap - Sherif Mansour
•
7 likes•2,889 views
The Art of Building a Roadmap
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (20)
Similar to The Art of Building a Roadmap - Sherif Mansour
Similar to The Art of Building a Roadmap - Sherif Mansour (20)
More from AgileNZ Conference
More from AgileNZ Conference (10)
Recently uploaded
Recently uploaded (20)
The Art of Building a Roadmap - Sherif Mansour
- 1. iPhone app Social sign-up G+ Integration Value Cost Q3 FY17 ROADMAP Referral program 7 6 4 5 1 8 8 2
- 2. Q3 FY17 ROADMAP VALUE COST iPhone app Social sign-up G+ Integration Referral program
- 3. SHERIF MANSOUR • PRODUCT GUY • ATLASSIAN • @SHERIFMANSOUR The art of building a roadmap
- 4. Understand your inputs Roadmapping — three ways The art of building a roadmap
- 6. Roadmap = set of decisions
- 7. Good decisions are made by first knowing your inputs
- 9. FEEDBACK CHANNELS PRODUCT VISION BUSINESS MODEL VISION THEMES FOCUS AREAS MEASURES Behind the Cloud salesforce.com/behindthecloud Company goals
- 10. FEEDBACK CHANNELS PRODUCT VISION BUSINESS MODEL Company Products Roadmaps OKRS VISIONTHEMESFOCUS AREASMEASURES OKRS OKRS OKRS V T F M Company goals
- 11. FEEDBACK CHANNELS Product vision BUSINESS MODEL Company goals What the future looks like and what impact you’ll have when you get there
- 12. FEEDBACK CHANNELS Product vision BUSINESS MODEL Test “customer satisfaction” requests against your vision Company goals
- 13. FEEDBACK CHANNELS Business Model FEATURE A VS FEATURE B wanted by lots of small customers a big, high-profile customer wants this Company goals Product vision
- 14. Feedback channels Company goals Product vision Business Model For each channel: Source Qual/quant Useful for… Watch out for… Cost (time) Weighting
- 15. The test: newbie product manager Company goals Product vision Business Model Feedback channels
- 16. Goal driven
- 19. Metrics as goals: A good metric Lean Analytics leananalyticsbook.com Understandable1 2 Comparative 3 Ratio / rate 4 Behaviour changing
- 20. Metrics as goals: Beware Lack of counter-metrics“Trial-and-error” approach
- 21. Create
- 22. Create … Blank pages Templates, and all the fancy stuff
- 23. # PAGES / USER EDITOR FEATURES TEMPLATES
- 24. Be data informed, not data driven… Good product design comes from striking the right balance between data, empathy and intuition. Alastair Simpson, Atlassian bit.ly/data-informed
- 26. Problems Over Metrics Problems as goals
- 27. Teams that fall in love with a problem have more successful outcomes than teams that fall in love with particular solutions. …knowing that a problem is worth solving continues to be motivating even when a team doesn’t come across the right solution… Julie Zhuo, Facebook bit.ly/buildingproduct
- 28. Frictionless page creation for advanced users* Create …
- 29. shortcuts adaptive design “frequently used” … preferences Frictionless page creation for advanced users*
- 30. Is there such a thing as an agile roadmap?
- 31. Is there such a thing as an agile roadmap? Yes, when you… Focus on problems
- 32. Is there such a thing as an agile roadmap? Yes, when you… Group problems into themes Focus on problems
- 33. Plan for “now”, “next” & “someday” Is there such a thing as an agile roadmap? Yes, when you… Group problems into themes Focus on problems
- 34. Agile roadmaps are problem driven
- 35. Build roadmaps around problems Goal driven roadmaps Data informed, not data driven Roadmap agility: problems and themes, not features
- 39. “The Homer”
- 44. Personas are
- 48. “The accountant” “The design wall”“The cheap layout” “The basic”
- 49. Better decisions1 Improved understanding2 Refined success metrics3 Anticipate feedback4 Personify (allthethings): Why?
- 50. Persona or role driven roadmaps focus on the user Persona driven roadmaps Personas drive roadmap decisions Personify features, not just users
- 52. Vision driven Persona driven Goal driven
- 53. You only evaluate a product once. Said me Agile NZ 2016
- 57. Lay tent pegs: Example
- 59. Lay tent pegs at the expense of table stakes
- 60. Build-a-box Vision driven roadmaps Lay your tent pegs Tradeoff table stakes for tent pegs
- 61. Vision driven Persona driven Goal driven
- 62. The art of building a roadmap INPUTS ROADMAPPING Your roadmap is a set of decisions Goals, vision, business model and feedback channels Goal driven (solutions, metrics, problems) Persona driven (by persona, by role, personify features) Vision driven (lay tent pegs, paint visions and boxes) Questions? @sherifmansour
Editor's Notes
- Hmmm.. Social sign-up, that’s probably a 4 in terms of value.. cost is 5… Oh, hey — sorry if you don’t mind I’m just building my roadmap, will be with you in just a sec. Google+ Integration… right, like anyone uses that.. that’s a 1 for value.. cost is 8. And the referral program… 8 and a 2.
- Oh, I know, I’ll chart this so It makes me look really good It will make it easier to decide on what to do next Let’s put value on one side, cost on another… And ahh, there we go…. looks like referral program and iPhone app is where I should focus. Roadmapping: It’s that easy, isn’t it? Unfortunately, this style roadmapping “give everything a score and you can work out what you need to do next” is pretty much all that’s talked about. And if that’s the case, roadmapping is probably mostly a science, and, heck, we should be able to automate it.. pack up our bags and go home. There are dozens of these prioritisation scoring frameworks. But in reality, I don’t think roadmapping is that black and white. It’s a messy process, and it looks different depending on where you are in your product lifecycle and what it is you want to achieve.
- I’m Sherif Mansour, been working at Atlassian for about seven years now and today I wanted to share with you how I believe roadmapping is much more of an art, then it is a science.
- And today, we’ll cover two main things Firstly, I’ll spend a short amount of time talking about he importance of understanding roadmap inputs. And secondly I’ll send some time exploring just three, there are dozens more, three ways which you might lead roadmap prioritisation. Hopefully by the end of this session you’ll have a few ideas of things to try with your teams when you get back when you’re building a roadmap and probably more importantly, I hope you’ll be thinking about roadmaps quite differently.
- But first I wanted to start with a story. Now I’m not a handyman, but the other day my wife wanted to buy a new bookshelf from Ikea. Ikea furniture: don’t get me started! But it was probably the most basic bookshelf you’ll see. Two sides, a back and lots of the shelves. So we ventured out to Ikea, and like always, you spend way more time and money there then you expected and are feeling quite frustrated by the end of your trip because you had to walk around this 10 kilometre maze to get out. We get home and I was going to put the bookshelf together. Now right, how hard can this be?! To be honest, I just opened the box and started putting things together, put the sides down, then the back, and with a hammer, nailed about 50 nails on the back of the sides and it was taking shape. Then I picked up the shelves to slide them in.. and … and… well, I put the sides on the wrong way around.. the grooves for the shelves were on the outside.. pretty embarrassing. ****CLICK**** When I get the instructions (even if I read them), generally ignore the beginning section of "What you will need". The temptation is too high when you open the box, see all the pieces and your mind instantly starts picturing how it will fit together – you just jump in and do it... Example of when I did this and got it horribly wrong. I didn't stop and consider all my inputs before jumping into the solution. The better you understand and use your roadmap inputs, the better your output will be. Far too often, people jump into building a roadmap without having a holistic and balanced view of their inputs.
- I was supposed to open the box, survey the contents and know the context I was in before I made the decision about how to make it. And today, if there is one thing I want you to think about is changing your perspective of a roadmap: I think we should be thinking about roadmaps like sets of decisions - decisions on what to and not to focus on. I wonder how often we think about that?
- … and before we make decisions, need to survey all our inputs. Let me take you through some key inputs you should be considering and some examples of how that might change the way you do this. These aren’t all the inputs, but in my mind, these are some of the ones that are too easy to forget.
- The first, and hopefully obvious one is the company goals. Our friends at Intercom use the phrase “a roadmap is a reflection of your company….you should be able to pick up a roadmap, reverse-engineer and guess the goals.” At Atlassian we’ve got something called the VTFM - stands for Vision, Themes, Focus areas and Metrics. This helps align the company when we see set our goals.
- VTFM framework is loosely based off a framework the Salesforce team created which was called V2MOM (Vision, Values, Methods, Obstacles and Measures) In short, as Marc Benioff puts it: The vision helped us define what we wanted to do. The values established what was most important about that vision; it set the principles and beliefs that guided it (in priority).” You can learn more about it in the Behind the cloud book.
- But the idea here is you’ve got your company vision and goals. ****CLICK**** Your products then form objectives, and key results (OKRs) around them - if you haven’t checked out the OKR framework, just google that. ****CLICK**** But then you base your roadmap off that. ****CLICK**** The idea here is you should be able to trace every single roadmap item back to your company goals… and if you can’t, you’re probably not doing the right thing.
- Second input you should be considering is your product vision. A vision is your take on how the world should work. Your view on the problem you’re trying to solve, or what a world could look like when you’ve solved those problems well - the impact of the change that you could do. If you don’t have a picture of what you’re paddling towards, you’re probably paddling in circles. A vision will typically take form of a video, set of concepts, document or a talk that is given to your team.
- Without a vision you’ll flip-flop frequently and find it difficult when to say no. A vision helps you know when to say know. ****CLICK**** Now the biggest culprit of items that are probably in our roadmap that fit into this are “customer satisfaction” features. Example: Customer satisfaction features that don't appear to distract, always customer suggestions highlight problems that should be solved - but is it you the needs to solve them? Every roadmap item you add is a decision. You should be thinking of your roadmaps as a set of decisions, every item you put on there is a trade-off. A vision will help you say no and focus your roadmap.
- The next one isn’t one I think we don’t think about that often. Over the last year, I’ve interviewed dozens of product managers at Atlassian. And one of the questions I love asking is this: ****CLICK**** Imagine you have two features you need to build, doesn’t matter what they are — feature A and feature B. For one feature, a lot of small customers want it. For the other, one big, high-profile customer wants. You can only build one. What do you decide? How do you go about deciding? (PAUSE)… I wonder what’s going in your mind right now? By the way, you’ll be amazed the amount of answers you get, where, even though you’ve said you can only build one.. somehow they’ve ended up with an answer where you’ve built both!! typical product managers! You get a whole bunch of answers. But one that rarely comes up is considering your business model. Depending if you’re in a lost cost, high volume business vs a high cost, low volume that should have a strong influence on what you decide to build.
- And lastly, probably the most obvious ones is where you get feedback on your product. And while this is the most obvious one, the one thing I’ve seen a lot of teams miss not have a balanced view of _all_ (not just the loudest or most used customer feedback channels). ****CLICK**** At Atlassian, we have a guide which shows people _all_ our customers channels and for each source we talk about different attributes such as….
- So my big test for making sure you’ve got your roadmap inputs is this: if you’ve got a new person starting on your team — what do you give them? Is this part of your own boarding process for a new PM? You’ve got a good grounding of your inputs what next? How do you make a call? ****CLICK**** At the start of the talk I talked about the cost/benefit approach — there are many flavours of this, and as I mentioned earlier, the main reason I wanted to give this talk is to show that the many other ways of building a roadmap. Today I went to share three…
- And, just to re-iterate, I don’t think there is aright way to do roadmaps — art, not science, all depending on where you are in your product maturity and lifecycle. What method LEADS your prioritisation? ****CLICK**** First up is a goal-driven approach to roadmapping.
- Hang on.. err shouldn’t all roadmap items have goals - yes, but there are a few things I wanted to talk about this method. When we talk about goal driven roadvmapping what do we mean? Well you can give a team a solution - tell them to build feature x, give teams a metric or give them a problem to solve in terms of goals. Let’s start with a solution. You know, developers LOVE it if you give them high-level solutions with very little detail. For example ***CLICK*** I have a user, they press a button, and we make money.. and make sure you highlight the important part - making money! ;-) I’m kidding!
- I’m not going to talk about why you should never give people solutions, I think plenty has been said about that, if you want to know more I gave a talk last year titled a “PM and a Developer walk into a bar” — a, hopefully assuming, set of anti-patterns. Giving them the solution is one of them.
- What about metrics? Metrics can be a great way to lead your roadmap prioritisation. We’ve found a metrics driven roadmap to be incredibly useful for growth teams, or teams trying to optimise a funnel or a particular feature — to increase engagement or adoption. There has been a lot said about how to set metrics, in fact a great read — if you haven’t already is Lean Analytics. If there is one section i’d recommend in this book it’s the section about “what makes a good metric” - chapter 2 I think. Understandable Outsiders: If they do’t understand or you need a page to explain it, it’s too complex. Comparative Being able to compare a metric across time periods, groups of users, or competitors helps you understand which way things are moving Ratio/Rate Ratios and rates (unlike absolute numbers) give you a more realistic "health check" for your business and as a result they're easier to act on. Behaviour changing What are you actually going to do differently? Are you changing the world or moving numbers from one place to another?
- Now the thing about metrics is that it’s all the rave right now. All the cool kids are metrics driven and they can be great for some things, but I’d be very careful about how you approach them. Two common challenges with roadvmapping around metrics I’ve experienced and hear about a lot from customers are Trial and error I have a three-year old son and he has a toy like this. What do you think he does when he wants to put a shape in a hole? It’s trial an error. He picks up a circle shape and tries to squash that into a triangular hole - and he can’t.. so he goes to try the next thing. You know, this method works — but it’s extremely inefficient. In a software world, you need to be careful that you don’t fall into this trap: You could have lots of good, logical reasons not to waste your time doing something, but far too often, people still do it because they go for the trial and error approach. Thinking and having a healthy discussion about a feature is a good way to avoid this rather than dismissing someones feedback. Lack of counter metrics This is about ensuring you’re not just moving numbers around. Heard a great quote the other day on counter-metrics: “Don’t just create a bar to jump over, create guardrails on each side of your beliefs” https://medium.com/@phineasb/counter-metric-is-a-great-phrase-49e550a35f95#.qgifqom2w
- Let me give you one example for counter metrics. Everyone here use Confluence? (hands up?) So we have this create button in Confluence and we started with a hypothesis: more people creating more content is a good thing. So we should reduce the friction to create content. When you pressed the create dialog you got a modal dialog which seemed to be sluggish and if you knew what you were doing, a very slow way to create content.
- So what we did we do? we split the create button. One side of the button went to creating blank pages and the “…” is loaded that dialog you saw with all the templates and add-ons etc..
- Results: Unique creators went through the roof, but what happened? We didn’t have any counter-metrics.. a few weeks later we noticed… Usage of templates went down. Usage of editor features went down (we’ve got editor features such as macros / tasks etc.. in templates to help people get started) Not only that, but as we reflected on it — strategically it actually didn’t make any sense either… We want Confluence to be a place where you centralise all your content, not just pages.. And we’ve got many people who build apps (we call them add-ons) on top of Confluence to encourage different types of content — files, diagrams, mockups, mind maps etc… Not only did it have an impact on us, but it also had an impact on our ecosystem of app developers.
- So the big lesson here is being data informed, not data driven. A colleague of mine, Alastair mentioned this in one of his blogs.. being data informed not data driven is how we should be thinking about using metrics. If you think about it, there are many other ways we can solve that problem and focusing on the data only at the exclusion of everything else may have some negative effects you’re not thinking about — we didn’t have any counter-metrics to keep us in track.
- So we’re not giving teams solutions as roadmap items — metrics, yes very good way, especially when you really want to get focused.. but by far, the best way to build your roadmap is around problems, not solutions and not metrics… If you give teams problems, they’ll come up with better metrics and better solutions.
- So we’re not giving teams solutions as roadmap items — metrics, yes very good way, especially when you really want to get focused.. but by far, the best way to build your roadmap is around problems, not solutions and not metrics… If you give teams problems, they’ll come up with better metrics and better solutions.
- Julia Zhuo sums this up really nicely - teams embracing a problem are much more successful than those that are asked to implement a solution. They keep their motivations up even when they don’t come to the right solution. https://medium.com/the-year-of-the-looking-glass/building-products-91aa93bea4bb#.ya85zemsg
- So let’s come back to this create solution example.. What is the actual problem we were solving? Frictionless page creation… important to note: really for users who already know what they are doing.
- So if we thought about it that way there are lots of ways we could solve that problem…. (animate). Focusing on the problem as the goal really helps us with roadmapping because it means we’ll explore many possibilities for a solution. The benefits don’t stop there. Focusing on the problem also helps the way we think about our roadmaps…
- Focusing on the problem gives us agility. I often get asked about this all the time. If you’re doing two or three quarters out.. how on earth is that agile? How can it be agile?!
- … and it totally can if you’re roadmap is problem oriented. Instead of drawing your roadmap bars with solutions think about phrasing them as problems.
- And for those of you with external customers, maybe you want to generalise that a bit more — if you don’t want to commit to the exact problems you want to solve, you can group them into themes. For example, let’s say you’re working on reducing email notifications for your app. One solution you may come up with is batching notifications. But that won’t be the only, and might not even be the best solution. Instead of writing “batched notifications” on your roadmap - you could have a problem statement of “increasing the relevance or improving the signal / noise ratio”… or if you wanted to go even higher you’d group that as a theme “Improved notifications”. What you do within that epic can change - but you’re communicating the high-level theme for your roadmap, not the exact solution.
- And lastly, you want to think about planning your roadmap in three concrete chunks if you can. I like to use the phrase “Now” - immediate, short-term, “Next” - next window of time and “someday” - yes you agree these problems need solving but the ordering an sequencing of them is not important to decide now. Deciding them now doesn’t change anything in the next 6 months - but you’ve indicated you’d like to solve them. Don’t go and plan / sequence your someday list - just don’t bother. It will change again in a few months.
- So agile roadmaps are problem driven.
- And that’s goal driven roadmaps — build roadmaps around problems, using data to inform decisions, not drive them — make sure you have that balance and finally focusing on problems and themes as part of your roadmap helps your team be agile in what they actually do.
- Next, I’d like to talk about another technique that might drive your roadmap priority — I call them persona driven roadmaps.
- Who remembers this Simpsons episode? This is a childhood memory of mine. Homer designs his own car, not sure how. And he designs it how he would like it. Crazy amount of cup holders Lots of horns A bubble in the back for the kids — so he didn’t have to hear them
- And when he comes to present it to the audience.. It’s quiet. Sock. Gasping — everyone things it’s terrible. It’s because Homer designed a car for people like him — his persona.. the problem is, there aren’t too many people in the world with a persona like Homers!
- Oh and by-the-way, someone has really built the homer — google it, it’s pretty crazy.
- A persona is an archetype of the users who use your software. Formulated form research of your users. And we’ve got these personas at Atlassian — in the form of cards. Here are some of them. They help our teams build better product as we plan or brainstorm solutions they help focus the conversation on who we’re building for. On the back of these cards are reminders, in the form of questions, to help us put yourselves in that personas shoes.
- By the way, we really do have them everywhere to remind us - even the bathrooms in our offices.
- Personas are traditionally used in workshops to help teams build features. But wonder if you think about building a roadmap around a persona? This is often helpful if you need to solve a problem from a specific users perspective or are trying to solve problems for a key buyer or influencer for your software. Here is an example of a roadmap opportunity backlog page for two of our personas - we’ve got Alana, and the opportunities we can solve for her on the left — she is like our BA. And Will, and opportunities on the right. So this can be pretty helpful in focusing the team.
- Now personas take shape of different roles. For example, our Persona Alana can be seen as a Business Analyst, Product Manager or Program Manager - she could have different roles. Basically she’s the “herder” / “Driver” sort of person. Another technique you could use for your roadmap priority influencing is completing the “flow” of a particular persona. Anyone here use Confluence questions? Well we’ve got three main roles - Asker, Expert a and Manager. And for each role, we’ve got the flow in which they work. As an example here is one for the Asker.
- Personify the features you are
- we personify a lot of things pages, spaces, features, macros etc… really about thinking in abstractions
- let’s go through an example with tables here are the different types’ so let’s say you want implement a feature like the ability to resize table columns
- personifying features help with a lot of things: Helps you make decisions by: Decide what you’re optimising (And not optiomising) for Identify the “majority use case” - sensible defaults Measure success make prioritisation decisions Anticipate the types of feedback you’ll get “for people that want this… we’d expect that…” Get your team aligned “oh I’ve got a good idea…”
- How should knowing this change the way you build your roadmap? how do you connect your audience with where you are headed? need to connect them to your vision… One way that we like to do that is with tent pegs… let me explain the analogy
- Internally we’ve coined this idea of laying tent pegs. Have a think about how you build a tent for a second - you first put the tent pegs down. Why? This gives you an idea of how the tent might take shape covers off a surface area for you to work in blocks off space in the environment you are in - so others can see where you are at What do you do next? You typically put up on side at a time until you’ve got your tent up
- So how do you build
- I’d even go as far as saying… Lay your tent pegs at the expense of tablestakes features
- What were our tent pegs? People (helping you see teams availability and travel plans), projects (helping you visualise projects events with your team) and events (social, training etc)… when you combined all of these views you could see how your teams availability could impact your projects or your team events - simple value prop. In our first release, we made sure that We had a little bit of all of these played out We went deeper down one of them - each tent peg has it’s own roadmap when you think about it In fact, we went a bit extreme here - we spent more time on a tent peg, then we did building what you’d call “Tablestakes” or “expected” features.. Think going broad - then deep Nobody noticed that we didn’t have permissions for the first two releases! (Even though we documented it in the release notes) - and the ones that did knew it was coming - it was an expectation.
- You only evaluate a product once.. if you’re building a new product or a embarking on a journey on a new epic - consider a roadmap prioritisation approach where you focus more on going broad — laying your tent pegs over prioritising what customers would expect for table stakes.