(upbeat music) (applause) - Thanks a lot.
How's everyone doing today? - [Audience] Good. - Yeah, good?
Is anyone going awesome? Let's get a whoo, whoo yeah! I'm really excited to be here today, all the way from Perth town, you know, the city of cockers.
And I regret not actually adding in a photo of a cocker to my slides, it's a missed opportunity and I'm just going to have to tweet hard about it.
So my handle is @the_patima, if anyone would like to tweet at me or have a conversation with me afterwards about road maps or anything product related or people related, culture related or doggo related, so come at me.
All right, as John mentioned, I've worn a few hats over the years and I wanted to kind of talk about this part of it, a little bit, following on from David's talk earlier this morning which was absolutely phenomenal. It was really great, good stuff. (laughs gently) So really what, you know John gave me the intro of saying hey well, essentially I've previously been, I've led a digital agency, I've also been a head of product and design. Yes there were two roles smooshed in there and a startup co-founder.
I've also been an individual contributor over the years as well and worked a lot in teams around design, dev, product, people, you name it, it's all been in there.
But kind of what I wanted to highlight is that a lot of these things are actually really annoying for me, to make me the type of product person that I am, because it means that I know enough to be really irritating to ask those questions. I've also, I suppose with a digital agency side of it, you can guess it, I can speak a bit of waterfall, which in product world could be a little cringe worthy. And startup you can YOLO it.
So all of these things smooshed together, essentially I just wanted to basically say there's no particular product shape that I have as a background, it's just I've always been really interested and fascinated and I've ended up where I am today.
So as John mentioned, here today I work at PetRescue and in this newly appointed role as the GM, I'm just absolutely thrilled to be part of this organisation.
For those who don't know of PetRescue, we're an animal welfare organisation based here in Australia, with the objective to create real social change and essentially at the core of it, for those who haven't heard of us before, we are a tech company and we use tech as one of the possible solution pathways to solve some really big challenges in the animal welfare sector.
So we also have a platform, an online platform which connects people who are looking to adopt pets or potential pet adopters with pets who are looking for homes.
And these can create really great stories, but there's obviously a lot of bigger problems at play and underneath it, and so with the organisation that we have, we've got a fairly small team and we're growing. We have to actually put a lot of work into uniting the team in the bigger picture strategy, because there's a lot of problems that we want to solve, but we can only do so much at one time.
And we wanna have the biggest impact that we can have as well.
So I wanna talk about this talk and what it will contain, because I'm going to be coming at it from a PetRescue lens and I suppose the problems that we wanna solve, talking through, rallying together around a shared vision and communicating the strategy to the team. So I want to talk today about what is a road map? Prudent and all the reasons to not have a road map, perhaps. How to decide whether a road map is for you or not. And part three is, if we are determining that we're proceeding with the road map, setting it up for potential success with some examples of course.
So this talk may also contain, as a disclaimer, traces of gorgeous pets, who are currently listed on the PetRescue website, all looking for homes.
Evie is, yup, is there.
It's so cool, it's just, okay.
And look, I know that typically for, when you're up on stage and you're giving a presentation, you shouldn't be doing plugs and pictures, but I'm going to shamelessly do it.
I have no problems with this whatsoever.
So hop on the PetRescue website afterwards if you are looking for a companion.
So let's hop into it.
Shameless puns as well, so let's do it.
Let's do it for Pete's sake.
- [Audience] Aww.
- It's great, thank you, thank you, I appreciate that. Okay, so let's get into it.
Let's start with, if we're talking about roadmaps, let's start with the definition of what a roadmap is. There's a lot of definition swirling around. And I've just highlighted a couple in this talk just so we can just get the gist of the purpose of them. According to Prodpad, and Apple and Cherry up there, a product roadmap is a visual document that communicates the steps you plan to take to make your product vision over time.
Product roadmapping helps you communicate where your product stands today, the direction in which it's moving, and how you expect to get there.
Sounds reasonable.
Another definition by David Bignall at Seek which I came across and Picolo came across as well, a document to capture and quickly convey teams, big picture goals, specific objectives, and their imagined path to success.
And my definition to it, to, why would I quote myself on this? This is odd.
But Penny and Nate would agree with me, I believe. I believe that the roadmap or a roadmap is simply a tool used temporarily or on an ongoing basis as a way to solve a specific problem, whether that's improving communication, visibility, alignment, creating conversations, or driving value. Also, with all things product related, it depends. So, I believe that for the purpose that I'm, that we're working through at PetRescue, it really is about alignment and then also visibility. So there's a few things that I want to dive in a little further into the talk with that.
So as I dived into this journey of roadmaps, and this started back at Seven West times as well, where we required a roadmap essentially to unite the engineering team and then also essentially different stakeholders across the organisation with the shared vision of what, where the product direction was going.
And what I found is, I kind of was looking at different ways to approach developing the product roadmaps, was that people either loved or hated or really, really, really hated roadmaps.
But you can't hate Marco, that's definitely another thing. And the people who are really passionate about it out there, the people who hate roadmaps, Kyle is one of them. This is taken a little out of context, but I've taken this quote out.
It's Kyle wrote a piece on product coalition, which was a really insightful piece actually. But one of the opening sentences is, "If I could pick one thing to kill "because of the problems it causes, "roadmaps might very well be at the top of that list." Okay, Kyle's not alone.
So, as with all times of uncertainty, we turn to a Twitter poll or I do anyway.
And in my extremely small sample size, the question I pose was, do you work with a roadmap or have you had experience in a roadmap previously? And, was your experience good, bad, ugly or, what's a roadmap? And what was really fascinating was actually, the conversations and the comments that I received afterwards, a lot of people slid into my DMs and had some pretty strong feels about their bad roadmaps.
And a few comments about some good roadmaps that people had.
So some of the comments and some of the conversations that followed. The bad, it's out of date as soon as it's published. It stops innovation, iteration.
It was more like waterfall.
It's just a gross corporate thing.
Pointless, constantly changed as the business priorities changed.
Tended to be based on what the business wants instead of what we have the resources to deliver. So these were a few of the comments that came my way, and I thought, "Okay, that's really fascinating," because what does that actually uncover is pain points for the organisation itself and the way that teams are structured around how much they've been hurt by roadmaps in the past. Beyond that, I also came across a meetup that I believe ran recently in Melbourne.
Did anyone attend these, oh, did you run it? Yeah, so just in my travels, yeah, The Good, The Bad, and The Ugly, and F Roadmaps up there.
I don't swear by the way, or I try not to mostly for the most part.
But it was really fascinating that there was a whole, there was a whole event planned around essentially hating all roadmaps.
But it wasn't that, it was really looking through the wrap up of it, and it's a great read.
I'll share these resources at the end as well for all to go through.
But reading through the wrap up, there was a lot of cautionary tales and wise words and wise advice that was provided to essentially guide people into the channels of good versus bad roadmaps and kind of those pitfalls to avoid.
So we'll go into a few of those as this talk goes on as well.
I just thought it was so fascinating 'cause it's sad, who hurt you? So generally, when I've spoken to people about their experiences with roadmaps and especially the ones that have had bad experiences is that they've probably experienced it from the view point of a tool that's been misused or abused in some way, shape, or form.
I believe that this negative sentiment kinda stems from not necessarily hating on the roadmap but what the roadmap caused as angst or anxiety or pressures unnecessarily on the team or individuals. And this is a tweet that came up earlier this week for me. I thought, wow, this is a potential time where, I saw quite a few folks shudder in the room there. This is a potential time where we could potentially have this conversation, I mean it's quite funny because the thought of a three-year roadmap and that being terrifying, why is that terrifying? Why is that something that people are shuddering at? And what is the intention of this ask? So I really wonder what, like I suppose its narrative continues to be because jokes aside, it really does, there's an underlying foundational issue that I want to address.
Intentions for creating a roadmap is really important to setting it up for others' success or failure.
It's like with anything that we embark on.
And if it's not tied, if a roadmap for this purpose is not tied to a clear vision or it's not, it doesn't have input from the customers and it doesn't have the research, I suppose, to back that direction, then it's already started off on the wrong foot. But is it the roadmap's fault? Is it potentially more the cultural or business mindsets that might've started off from command and control structures that have caused these pains? And I suppose kind of going on without, I want to pose the question to you all, you know, I suppose, say if we might be able to rally around this thought that if roadmaps have such a bad rep, then who has actually contributed to this story and this narrative and this background that narratives have, that roadmaps have? Is it us, the product leaders in the room, or people who are leading product teams or the products? Is it us that's not, said no at certain times when we've needed to? Is it us who haven't asked the questions? Because someone set up these roadmaps and someone's gone along with actually causing some of these pains.
So I just want to, I suppose, take this moment to just acknowledge our responsibility in it as well and what we can do to create a new story and narrative for said roadmap. And look, I'm not one for shaming.
And I wouldn't normally endorse shaming, but there's this great, in case you're, I'm not sure of the reference here.
There's this great, great website called Dog Shaming, and it basically just, yeah, dogs are naughty. They can be really naughty.
And look how cheeky that face looks.
But yeah, it's essentially, dogs get a guilty look, and I wanted to tie this in into some of the areas of responsibility that I believe we could actually understand that these are areas which we can improve on.
So, in this example, I created a roadmap that contain dates, putting the team under pressure. So that's probably something that we want to avoid as a potential trap.
And going down the path of, again, timeline related roadmaps, which then become a potential series of promises which are really difficult to keep sometimes, especially as we, at that point in time, might learn new things that change and evolve that roadmap. My roadmap is too rigid, leaving no room to explore ideas, innovation, and improvements. I'm sad, so guilty.
I created a roadmap full of feature ideas and then the sales team treated them as promises. Aww, that face.
I created a roadmap because I was told to, then tried to force it onto the team and they didn't use it. I created a roadmap from stakeholder request. I added my feature wishlist too, shame.
I created a roadmap, published it, then didn't update it again.
I was too reactive changing our roadmap too often unsettling the team, could be a problem.
I thought our backlog was our roadmap, and I never removed things.
Probably that second part is the more important bit. I created a roadmap without a customer focus. I haven't spoken to any customers, shame.
And, I didn't say no to the CEO.
So I wonder, look how guilty, guilty, guilty. It's okay to say no by the way.
So I wonder, you know, this narrative leading on into, going back to this tweet that came up in my feeds. And you know, whether there was that opportunity for this person to explore these areas of potentially mitigating these users and misusers and abusers of potential roadmap applications and implementations.
So, I suppose in summary for that is with the concept of bad and bad experiences with roadmaps, just to recap, they're misused or they're abused when they're rigid, and they don't allow room for innovation and ideas to actually flow and have room to move in. They contain dates and features which are then treated like promises, which then puts people and teams under unnecessary pressures whether that's the C-suite, whether that's the leadership team, whether that's individual contributors.
It's something that's not ideal if you have promises that have been, a part that's been set out in front of you with a series of promises that you might not necessarily have agreed to.
They force, they could also be forced onto the team and therefore not embraced, which make them a pretty useless artefact to have.
And sometimes, they can be hijacked beyond the intended purpose.
So, these things can happen, and being mindful and aware of them and acknowledging that these are things that happen in various organisations, it might be happening in yours right now, or you might have experienced it in the past, gives us the opportunity of actually addressing this problem statement and us posing this question by Evie, also on the PetRescue website currently.
What if we could give roadmaps another chance to be loved, could we love, could we love roadmaps as a tool for our businesses, our products, our organisations? Maybe, maybe, maybe.
So let's talk about that.
Let's talk about the potential benefits of having a roadmap. Or of not having one according to Joe.
Without a strategic roadmap, teams can be working on something that has zero value for the customer or the product and not even realise it.
Seems like potential misopportunities there. John Cutler, who I believe is one of the most excellent product leaders out there has written some great pieces, and he posed this question, or these questions and these thoughts, which was really around the benefit of roadmaps for teams that have shared roles or whether there's shared roles that go across the organisation like UX, research, design, data analysts, insights experts.
David touched on the fact there might be different ratios to team structures as well in the luxury pod kind of structure where you have a designer and a product manager or a product person and also an engineer or three in that kinda structure would be a dream, but there's often, you'll find that there's a few designers that are shared across multiple product teams. So John wrote this previously.
Why not just give teams their own backlogs? Why do we even need to view this on one board? Okay, that's the problem space.
Well, chances are the teams don't have 100% dedicated team members.
To do their job, roles like Ops, Marketing, UX, et cetera will need an overview.
So a potential, really strong benefit for having roadmaps. So, when we're talking about defining a purpose of the roadmap, and this is about setting that status of whether we actually, whether we even need a roadmap in the first place.
And this is that self-assessment point, I suppose bringing that product thinking into it. Do we even need a roadmap in the first place? Well, answers are it depends.
And it depends on why, like I suppose what the ask is that you have going for the roadmap.
Are you saying, if there was a statement that best represented having a roadmap in your organisation, I can't speak at the moment.
Do you say, "We must have a roadmap," or, "We need to have a roadmap," or, "We should have a roadmap," "We could have a roadmap," and, "We won't have a roadmap"? So I suppose this language matters, and this language is going to set up your feature roadmap, if that's the tool that you choose, for others success or failure, because there's only a couple of options up there that leave room for flexibility and leave room for that movement and then that exploration as well and give options to the people who are leading said product. So I want us to take a moment to look beyond the hammer with Billy, and essentially, question whether the roadmap or is a roadmap the tool for you. And when we're talking about looking beyond the hammer as the little tool, the hammer can do a lot of things. It's this age-old analogy of what is the purpose, or what are you hiring or purchasing the hammer to do. Is it to just have a hammer or is it to nail a nail, hammer a nail into the wall, is it to create the hole in the wall? And the question of why do you want to actually have a nail in the wall in the first place. Is it hang up a picture or maybe you just want a hammer because it's a tool that you wanna smash things with? Look, whatever that intent is or the reason why is really important to actually set the context of the tool versus what you actually are going to be using it for and what you're essentially hiring it to do. So let's ask these five whys.
Here's a potential narrative of breaking down why one might need a roadmap.
Would it be, okay, communicate, why do we need a roadmap? To communicate our priorities clearly to stakeholders. Why do you need to do that? So that they know what is planned and why.
Why is that important? So that we can have their support on the work or so that they know they can be represented. Okay, and why? Because our stakeholders asked for new features when we already have other high-impact work on putting our team under pressure.
Why does that happen? Because they don't understand what we need to trade off to get new work included.
That's a potential narrative that I've heard in the past. But understanding that means that we can actually go, Well, what is the actual purpose to having the roadmap as a tool to serve? And if that's about actually creating that conversation and repositioning with stakeholders or the fact that they don't understand the work that the product team do or the product and engineering team work towards, then maybe that's actually, maybe starting there might be a better place than having a roadmap. Another narrative could be a more internal focus one. Or maybe you want to work towards that team unity type focus Why, why do we need a roadmap? Communicate our priorities clearly to the team. Why do we want to do that? So that they know what we're rallying towards as a team and why.
Why might we wanna do that? So that we can focus our efforts towards united goals. Why is that important? Because we can sometimes get distracted from the high-value work.
And why does that happen? Because we might not understand the bigger picture. So again, another potential narrative that can happen. And your stories will all be different.
Your organisation structures will all be different and the purpose and the why's behind why you might embark on a roadmap or have a roadmap might be totally unique to your own situations. And in fact, I expect that they should be.
But asking these questions in any situation provides that diligence of actually understanding the real background to it.
I just wanna take this moment to pause and just, Let's look at these doggers just doin', doin' his own thing, even though there's a, a clearly laid out plan. And look, sometimes, things don't go to plan, and that's okay.
I love this dogger.
Okay, so let's hypothesise here.
If after this work and this assessment and this pre-validation that we've done, we've determined that the roadmap is the tool for you. Let's set it up for success rather than failure. And now, having spoken about, leading up to this point, the potential, the bad experiences that people have had from roadmaps, we have the opportunity to mitigate those and prevent those from happening or approach those from a lens of going, okay, well, we need to get this tool as a roadmap to work for us, rather than the other way around.
Four super simple things that we can do, and this comes from having that product lens over it and using our skills to full force here.
Defining the purpose, which is the why.
So we've talked about that.
Define the audience, it's like, are we working towards a product market fit here for this roadmap to be implemented? Design the content, which is looking at what goes into the roadmap and building it and shipping it. And then of course iterating on it afterwards. But we'll go through that motion in a little bit as well. Firstly, it's time to dog-food it, do you get it? So let's create a roadmap, and let's go through the process of potentially creating a roadmap for PetRescue as an organisation.
So start with why or the reasons behind why we might create a roadmap for PetRescue. And some background context is going to be really important for you all here, which is that I've been on board with the organisation for six months now.
Ooh, it's been six glorious months, it's been so good. But yeah, essentially what the challenges are, that it's, everything's been, in a technical sense, been humming along really well, but we have some bigger things at play here, and we actually, we really need to have the team working on the same trajectory so that we can work towards having the most high-impact work.
In the lead up to that, there's a lot of work that has been identified.
There's no shortage of ideas, and they're brilliant ideas, but all of them will have a different type of impact. And some of them actually create or generate different problems by just existing in the first place. So what I had as an intention for creating or even looking at creating a roadmap as a tool for the team was just to take that moment to take stock and gather and group what the different pieces of work that we actually have them to go work so that we might be able to then understand what's been important to us and whether that is still the case and where we can identify areas of learning, and learning and shifting as we need to.
So let's go through this process of the fireflies. Why, why do we need a roadmap? Well, we have a lot of work on the go, and we want to have a visual overview of it, because we want to see what's ahead of us in case we need to approach the current work differently, because this is new thinking for us.
At the moment, ideas are sitting in minds, great minds, all in the backlog, and we can't necessarily see how they all fit together, and we being the collective as the team across the organisation and if they fit at all. And why is this important? We want to make sure that we're focused on the highest impact and have a shared understanding of our priorities or maybe just the chance to even prioritise in the first place with knowing what, what is existing currently and taking stock there. And why is that? Because we want to save more lives.
So what's really important for us is there's numerous ways of saving more lives and creating happiness, and in animal welfare sector, as I mentioned, there's numerous problem statements that exist that we want to essentially work through. But with work that we've got on the go, we want to make sure that we're having the highest impact. So we're talking about value in a product mindset. With PetRescue, we're really impact driven, and we want to be able to save more lives.
And while every life is important, we want to be able to do that for as many lives as possible and affect that change. So the purpose statement could look like based on that, We're looking for a tool to generate conversations about the outcomes that we're aiming to achieve.
We want to combine what we currently know and have planned based on the current information we have at hand and to deliver on our mission, to create happiness and save lives.
So really from our purpose statement, it's not, this would look very different for a startup purpose statement for a roadmap.
But yeah, for our purpose, it's really about taking stock and taking a moment to actually go, okay, where are we right now? Where have we identified that we wanna go? And what are all these bits that currently exist in between? And are they still relevant, do we take some away? But without actually having that visibility, it's really hard to see that.
And then going on to the next stage of it is part two of defining your audience.
And this will determine the level of detail, and this is the content piece, that we might include. And that will be different depending on who your target audience is for the roadmap. And I've put a note here, is that it simply cannot be everything to everyone. And I've seen in the past stories of where this has, this has been a situation where a roadmap's being developed and then it's been given all wide.
But the levels of fidelity are not the same. The types of detail that are the CEO or stakeholders or investors might need is different to what the product marketing team might need, which is also different to what the engineering team might need and researchers and sales and customer support, so on and so forth.
So let's define, you know, who's it for.
Does it exist as something that's public or is it internal because that content that's going to exist in there is going to be really unique to that audience and what you say and what you don't say, depending on whether there's your brand awareness versus making promises that you might necessarily struggle to keep, and then versus internal, which can be more detailed, depending on which group in your organisation are looking at it. And yeah, so I mentioned product marketing might need to understand what's coming up, what's coming ahead so that they might be able to plan their own roadmaps, if they have their own roadmaps, to prepare for other launching of product or for preparing for a new release that's going out or preparing their comms or developing pricing models. These are all things that will be relevant for them to be able to actually understand what's ahead. The engineering perspective is different or even any of the IC disciplines, from design to engineering to research, and they might be referring to, they might be referring to the roadmap for the purpose of looking ahead at what's coming ahead and then looking at solutioning that might be able to better with the things that they learned along the way, might be able to position the high-value things upfront, or rather than approaching one pathway, they might approach it from a different pathway knowing what's ahead.
This is also important for customer support. I'm sure you'll all agree at the frontlines with customer support teams potentially being able to use the roadmap as an option you need to generate and drive those conversations and reassure the customers coming ahead, the customers coming to them for support that upcoming fixes might be planned, or upgrades or things that are happening in the pipelines and being really careful about what these are with the customer support line.
Sales have a very specific purpose which is to convert. So they might use a roadmap for the purpose of communicating upcoming features or functionalities that can get potential customers over the line. So that's a really different intention of having a tool such as a roadmap.
They can, like I suppose, these are the goals that they would have with their KPIs, wanting to reach new levels or new goals and essentially get new customers on board, which is super important.
But if your roadmap is for internal purposes only for the engineering team, perhaps knowing that that will change along the way as we learn, as we learn, as we go along in the journey, maybe that's not a great repurposing of an engineering roadmap for the sales team.
So the content would need to be designed deliberately for their lens.
And again, the level of detail for CEO or execs or if we're talking about stakeholders, they're looking for a different level of fidelity there. They just want high-level goals with strategic planning and knowing that the organisation is tracking along in-line with the company or the org's vision potentially. But taking these things into consideration is really important to actually understand how we might put together the content for your roadmap. So in PetRescue's case, at this point in time, we are working on the roadmap as an internal tool. And specifically, the example that I want to go through today is our tech roadmap. And it's built for internal consumption at this point in time.
And remembering the purpose that we had which was to inform and unite the team towards a shared vision and actually just taking stock on the current work that we have right now. And it's really important to note that this is just a starting point for us.
We've got a few different versions of roadmaps going around and we're exploring, we're exploring what is going to work for us. And we have different content fidelity depending on which team in the organisation we're speaking to, because it's really, yeah, it's really important for an org-wide vision to be shared as well.
And yeah, so I suppose, right now, we're in that assessment of do we, do we ever want a public roadmap that is really that higher level look into what we're about to, what we're embarking on in our mission and vision.
So, it's worth exploring whether you might actually require more than one roadmap or having different versions of your roadmap. So you might have a master one that exists for specific purposes, and then you might repurpose that for the likes of say stakeholders, external and sales. There's definitely opportunities there, and it's a tool for communication at the end of the day. So that could work.
And I don't think we've had a dogger picture for a while, but this is Beau.
And this statement, Build it and they will come, spoiler not really, that won't happen, unfortunately not. But if you call Beau, he'll probably come.
I mean there's a, I'm on fire, yeah.
Look, unfortunately, it's just not that easy. And with every tool that you take on, anything that you explore, there's some work to be done there.
So we have to commit to things like, okay, how do we design our content, and then how do we actually build and deliver said roadmap as a tool? Okay, so let's talk about the types of roadmaps. Cool, so we've got, type, there are types up there. Hopefully, no surprises, but we can go through a few of these in detail.
But I'm just gonna drop out a few of these now. I'm taking out the time concepts of the Gantt timeline type roadmap because time roadmaps with deadlines are a lie. Up and to the left and skeuomorphic, don't worry about it, but I suppose from the, for the purpose of this presentation, I just want to take you through the specific concepts that I've had experience with. I'm going to start with the feature roadmap, which is a really fascinating one because there's the features, the whole features conversation and the concern or the fear or the gap or rather the red flag that this could be a series of promises that, how do you know what features we're going to build down the track if we're not planning for room to iterate on to move, and it becomes a checklist of features to get out there, and we become a feature factory.
So that's not ideal, but we can watch out for those things, you know, the promises trap and the shallow gap. And knowing those areas, it might still be a really beneficial type of roadmap to have for public view. And it is mostly relevant for that kind of, that higher level view of what's coming up. And especially depending on the stage of the product and the product that you're working on.
So I wanna talk a little bit more just on this bit about product depth and talking, quoting Joe again. Focus creates product depth, and product depth always trumps product width.
A deep product may solve limited problems but does an excellent job at solving these problems. Shallow products do a poor job at solving a number of problems and are often filled with gaps and workarounds. So to demonstrate this visually, there's when we're talking about features and features sets and talking about depth in product versus these gaps that are identified here, that's really going to set you up if you're going down the path of a feature-driven roadmap.
And this piece of reading, which again, I'll share these resources at the end, is a really great resource to actually identify those areas where you might ask those question on product gap. And I would just quickly say this one cause I think Dom is around.
I don't know if he's around today, but the only roadmap that I have seen is a feature roadmap where I've gone, "Yes, this is amazing," which I generally wouldn't endorse feature roadmaps, is The Tree of Up, and that's on their website. And there's also, I suppose, beyond this.
This is what the public view is, a little sneak peek via another presentation at the internal view, which is obviously not this shape.
It's up on a wall and it's a tree as part of processes, so I'd love to find out more about that.
But I hear good things.
Onwards is talking about roadmaps of outcomes versus outputs.
I'm just going to kinda skip forward here because I am running out of time.
So, I wanna talk about OKRs, theme-based roadmaps, time horizons, mind maps, and columned approaches. And I just want to refer to Janna, who is the absolute legend on all things theme-based and time-horizon roadmaps. So I won't read out this quote, but I want to refer to the resources that she's spoken about and written about as well. So she talks about the different time horizons here of current, near-term, and future, so that we can prioritise in that way and also things to actually tie-in concepts of thoughts there. Cool, so, I suppose going on beyond or continuing on the themes thought is being able to tie, I suppose, outs and in and bits and pieces on what people have identified as input points as pain points. And looking at the overarching goal of what is it actually that you're wanting to achieve when you hear inputs like, I didn't get a notification email after I made a purchase, It's hard to tell if I'm putting an item on my wishlist or in my shopping cart, Why can't I pay with PayPal? for example.
These things all group into a theme that might look like how can we deliver or improve on our checkout process.
And then, that way, rather than looking at each of these as individual things to solve or fix, we can actually take a step back and design it in such a way that it might front load impact first. Language is important, talking about outcomes versus output, so avoiding actually determining what the solution is before discussing it creates a space for ideas and innovation to flow.
So this is important when you're setting up the box on your roadmap, as I affectionately call them. But yeah, there's opportunities for that divergence and convergence in those conversations. So let's quickly talk about the example of the PetRescue roadmap as I mentioned from like a format view point. We've got one which is the mind map.
And the purpose of setting up a mind map such as this was actually to take stock and take that moment of the snapshot in time for us and what was ahead. The detail of this is really vague, and purposely so. It's the idea of creating the conversations, understanding what things actually might relate to other things, and the streams of work. I suppose this is the really important part because this leads into the current areas of work and how it categorise the pieces of work to front load the themes essentially running through it, for want of a better term.
So things such as brand repositioning and communicating our vision, support Org and MarComm capabilities.
It's a core piece of our work as well, only a small team. Continuous improvement and creating that room, that space for dev workflow, foundational work, product health.
Matchmakers is our online adoption platform. So a lot of the work that we do actually revolves around the goal sets of improving the experience for members and the adopter experience.
So they're the kinds of success signals that we set. And of course, as a charitable organisation, sustainability and fund-raising capabilities are key for us. So we've developed themes out of that mind map essentially that always put together, and it was sorted with inputs from the organisation as a whole, the developers, the designers that have worked with us, the marketing team, it's essentially, it was getting inputs from all of these different internal stakeholders.
But then we also included in the customer support. We talked, so the customer support conversations that we've been having and identifying those pain points as well and grouping them into themes of, okay, well, what's important to them, what's important to the organisation? And how do we actually prioritise these areas? So we've grouped into this foundational themes as mentioned with the green box there.
But then it's also, you know, how do we support the organisation going forward, what does improve adopter experience mean, what does improve member experience mean, and what are the OKRs that might surround those as success signals? So it's this opportunity for us to have those conversations without actually saying specifically, "This is the solution for it." It means that we can explore and go deeper and ask those questions off each other and actually research and find out why there's a need here. Cool, okay, so last final bits for me is then, of course, with looking at it from a product mindset is not just shipping it and then forgetting about it. Again, we wanna set this up for success, so we want to incorporate it as part of our workflow. Where that sits in your current workflow might be different to where it sits in someone else's organisation.
As an example for us, we've got, we're a distributed team, and a hybrid distributed team at that, so we have a regular weeks as a team, and we also have a new ceremony, a new monthly thing, which is a look-back.
And in that look-back, we look back at the month that was and then we look ahead at that what's coming ahead. So we have actually added in this roadmap as part of that process for us.
So as a team, we can go, "Okay, we've done this "and we've achieved this, let's celebrate, fantastic." And then moving on, what's coming up next.
And the fidelity of that, the detail gets fuzzier as we're kind of going feature vision.
But knowing that we're united in the goals and it's really clear across the organisation of what the engineering team are working on, as an example, is really important to get that united and shared understanding.
So like with the product, it will have different versions of it if you need to, depending on the audience. Maintain it, iterate on it, get your feedback, get your inputs with it so it doesn't just go out there into the wild and be an artefact that's not maintained or developed on or improved on, and constantly reassess that why. Why did you, why do we have this roadmap? Is it still relevant? Is the purpose of it no longer the purpose of it? Final three takeaways, it's not a turn-key solution. So you're going to have to work at customising it for your own needs based on that identification process that we're talking about and treating it like a product. And remembering, that's the wrong order, Patima. Remembering that it's only a tool.
And the tool is as good as what you make of it essentially. And the tool doesn't control you, you control the tool. So, also, Shilo and Rocky, who are a bonded pair, so they come as a pair, it's really cute.
Thank you very much for listening.
Please come chat to me about anything roadmap, people, ops related, product things, adopting a pet, workplace foster care programmes, a bunch of things up there, good reading and references which I have plenty more to tweet out over time. But thank you very much for your attention and enjoy the rest of the conference, cheers. (applause) (upbeat music)
