Is your roadmap delivering value? | Andy Budd
In Talking Roadmaps Episode 70, Phil Hornby interviews Andy Budd to explore whether roadmaps truly drive value. Andy, a designer-turned-investor, introduces the Growth Equation, a framework for startups to reach product-market fit. They discuss the role of roadmaps in balancing feature development with value extraction, the importance of growth teams, and the tensions between product and marketing. Andy challenges traditional roadmapping, advocating for problem-driven planning over feature lists. A must-watch for product leaders navigating growth strategy.
Andy is a Designer turned Investor, Advisor and Coach. Andy recently became a Venture Partner at Seedcamp—one of the most successful and best-known early-stage venture funds in Europe. As well as helping source and review new investments, Andy uses his knowledge of sales, marketing and product-led growth to help portfolio companies prepare for Series A and beyond. Andy has summarised this experience in his new book, "The Growth Equation." In it, he aims to help founders find their early customers, land their first $1m ARR, and reach Product Market Fit.
Prior to joining Seedcamp, Andy founded and sold Clearleft, an award-winning design consultancy which pioneered the field of Web Standards and User Experience Design. During this time he helped clients like Just Eat, FarFetch, Rapha Cycling, Funding Circle, Mozilla, Virgin Atlantic, Penguin Books and Burberry make the most of their digital experience. While at Clearleft Andy also helped found the Leading Design and UX London conferences, a community of 2,000 Heads Directors and VPs of Design, and a city-wide arts and culture festival in Brighton.
On top of working for Seedcamp, Andy advises a small number of founders on the concepts found in his book, as well as coaching high-potential design and product leaders. In his spare time, Andy—a former dive instructor and “shark wrangler”—loves exploring underground cave systems and tropical atolls. As a recently qualified pilot, when he’s not under the water, he can be found soaring over the Sussex countryside in a rented Cessna 172.
Here is an audio-only version if that’s your preferred medium - and you can access it through your favourite podcasting platform if you prefer (Apple, Spotify, Amazon).
That’s a wrap! We’ve finished Season 1. Coming soon is Season 2 where we will be diving in Product Operations. What this space!
-
Andy Budd:
You know, I argue that startups, products really, are a vessel for value delivery. If your product can't deliver value, and it can't do it quickly, and then repeatedly, people aren't gonna stick around.
Phil Hornby:
Welcome to "Talking Roadmaps." Where we'll talk about everything roadmapping, the good, the bad, and the ugly. Today I'm joined by Andy Budd. Andy, introduce yourself.
Andy Budd:
Oh, well thanks so much for having me on, Phil. So, yeah, as you said, my name's Andy Budd, and I am a Venture Partner at Seedcamp for two days a week, which is a early stage at a precede seed stage VC fund. And I am a advisor and coach to both designers and to founders for the other two days a week.
Phil Hornby:
If you're enjoying the channel, subscribe, hit the bell and give us a, like. I know you're also an author, Andy, so just tell us a little bit about the book and what space that covers.
Andy Budd:
Prior to working in VC, I come from a design and product background. I used to run the UK's first UX agency for about 15 years. And so I have a kind of a strong kind of design and product background. When I moved into the VC world, I started having lots of conversation with early stage founders, and I started to realise that a lot of the problems they were having were the same problems I was used to dealing with as an agency person. And a lot of them were related to growth. And so I realised particularly as a VC, if you are trying to move your product forward, often it's in order to show a certain level of traction to get the next round of funding. That round of funding then unlocks the opportunity to build even more product, to grow your team, et cetera, et cetera. And so a lot of the problems growth was at the heart of the conundrum. And some of it was kind of like, you know, particularly early stage people are on that route to kind of product market fit. And so some of them were market problems, some of them were revolving around not having a big enough audience or having an audience that didn't really care, you know, sales, marketing, strategy. And some of them are around products. You know, we, we have a product, but is it delivering value fast enough? Can we onboard people sufficiently? Can we retain them? And so I kind of discovered that there were sort of like seven factors that had a really outsized impact of on growth. In fact, pretty much every conversation I had, could come back to one of these seven factors. Five of them were really positive that could help, you know, accelerate growth and two of them were negative. That would kind of slow growth down. And so I started to formalising this idea of like the growth equation, putting these seven things into a little formula. And off the back of that I started writing and it started being an article then a series of articles and it ended up being a book. And so that's what the book is about. It's called "The Growth Equation." And it's really about how startups, product teams, founders can navigate the first two or three years of their company pre-product market fit. So how can they get to product market fit, and how can they grow their business pre-product market fit?
Phil Hornby:
And I'm sure that's gonna bring in really interesting early stage growth, kind of dimension to us talking about roadmaps here today. In fact, I wonder if any of those factors appear in our roadmap. Maybe you could tell us what those seven factors are, and then we can kind of explore from there.
Andy Budd:
To start off with like, this is not rocket science. Like these seven factors are not some kind of magical, mystical, or, my God, I've never heard of these before. When I talk to you about them in a second you'll go, well, duh Andy, that's all obvious. But what I've found is like a lot of startups are trying to find like the secret, magic code that only they've ever heard of, that will then unlock growth. And actually a lot of it comes back to basics. It comes back to hygiene. So the first factor is audience. I meet so many founders that spend all their time building and haven't cultivated a big enough audience. And so, you know, if you don't have a big audience, you don't have enough people coming and discovering your product, then you're not gonna have enough people activating, retaining. And so the first thing is audience. However, it doesn't matter if you've got a big audience unless they're motivated, you know, unless they have an understanding of the problem your product solves. And that problem hopefully is a kind of a painkiller type problem rather than a vitamin. Something that kind of pushes them to your products and drives them through the product. So the second argument is motivation. How can you build and manage the motivation of people? And these two elements sort of are the market side of product market fit. The other sort of five elements are more the product side. And so I think one of the big things for me is value delivery. You know, I argue that startups products really, are a vessel for value delivery. If your product can't deliver value, and it can't do it quickly, and then repeatedly, people aren't gonna stick around. And so I think one of the main things that product people do is focus on the delivery of value. And actually a lot of the issue around roadmaps is are we delivering enough value and what features or functions do we need to put in? What capabilities do we need to add that can deliver even more value? But there's a caveat with that, which I'll get onto maybe later in the conversation. But value delivery. And a lot of it is around speed of delivery. So actually it's value delivery over time. I meet so many startups that the value is there, but it's hidden, it's not obvious. And it takes users weeks and weeks and weeks to kind of discover that value. And if you can't kind of hit users in the face straight away with like, you know, on the first run, on the second run, here is value and keep delivering that value, they're never gonna get into this sort of habituated place. And so the next argument is stickiness. Your product's, natural innate ability to grab hold of people and keep them into the product. Obviously if you have a product that starts to be kind of sticky, it retains people, then you also want to use it to acquire new people. So the next one is the K factor virality. You ideally, like everything around product-led growth is like how do we create sticky products? How do we kind of build usage loops? And then how do we build acquisition loops? That's the virality. And so virality is hugely important. And so those are the five elements that have a positive effect. The two elements have a negative effect are friction, you know, this is classic design stuff. I see so many products that are difficult to use that are lumpy, that are bumpy, that kind of put barriers in the way of accessing value. And so reducing the friction makes everything else work better and adding more friction kind of like reduces your ability to grow. And then the last kind of major factor is the competition. What everybody else in the market is doing to, you know, the same stuff in the growth equation, but to kind of pinch your customers, to draw your customers away. The only thing I would say with competition or the market is that when I talk to founders about competition, they're always thinking direct competition. Like, oh well you know, there's nobody on the market that has exactly the same feature set as me, we're special. Or like, oh, you know, we've only, you know, even though we've got hundreds of competitors that I only see these three or four people as competitors. For me it's the whole competitive landscape. And for a lot of startups, your main competitor could just be a free spreadsheet, it could just be a free Google sheet that people have been using and it's a bit lumpy, and it's a bit messy and it's not very slick. But when they start using your product and things are difficult and challenging and the value isn't there, they just default back to the old way of use doing things. And so those in a sort of a nutshell are the kind of the seven arguments that make up the growth equation. That's chapter one by the way. So really that is just an introduction to the kind of the challenges that people face with growth. The rest of the book is all around how do you do that? How do you decide whether you have a product led, a sales led or a marketing led approach to growth? How do you decide what good onboarding looks like, what good activation looks like, what retention looks like? How do you decide how you should price, how do you use behavioural science to kind of keep people there, keep people coming back for more. So really the book is like a guidebook of the first two or three years of a startup journey, but for your audience, like I pitch it towards startups, but really it's a product book. Like it's a product book in stealth. Like this is all the stuff that you as a product team want your founders to know. But if you sold them a product book, they wouldn't read it. They'd go, oh, I'll hand it to my product manager. So I see this as like all the core learnings that if your founder can really get and get excited about this is the stuff that you and your product team will be delivering over the next two years, five years, 10 years plus.
Phil Hornby:
So I mean I kind of take the position that the product manager is often, especially as a lot of organisation skills, he's often the entrepreneur in the room 'Cause the founders are off doing the funding bit and the entrepreneurial work of actually going and creating that value in the market and driving it and kind of taking it to market often ends up landing on the product people's shoulders. Like I spotted you put out a 10 practical startup books list recently. It has my favourite product book ever on there, it has "The Mom Test," which I remember getting from Rob himself at the Lean Conf back in 2012 up in Manchester, which was the first Lean Startup conference and it was full of product people, me amongst them.
Andy Budd:
I mean look, my honest hope is, that I think if the growth equation could be anything like "The Mom Test," if you could anything like "Obviously Awesome," like these are books that if someone says I've got a branding problem, a positioning problem, or if I've got a kind of a customer discovery problem, you just say to your founder friends, take this book. My hope is the growth equation will be the equivalent in growth. I've got a problem with growth, a problem with acquisition, we're not growing fast enough. We'll go and grab Andy's book and that will help you solve that, so. But I think the value of all these books is they're aimed at startup founders, but they also teach product people about business, about the things that are really important that are driving the mentality. And also particularly something like "The Mom Test." Like the mum test is about design research really, But you go and try and talk to a founder about design research, they're not gonna listen. You talk to them about customer discovery, they might listen, but if you frame it in a language that they kind of get, they understand, like you are training them and teaching them about a skill which is important to you, but which if you sold it to them in your language, they might not have the time for or care about. So yeah, framing is massively important.
Phil Hornby:
The framing of the book that I'm working on, which is very much pitched at product people, but should I be pitching it at the founders instead? I'm gonna have to go and reflect on that a little bit more over the next few weeks. So okay, let's bring it really down to earth. And so we had those different aspects of the growth equation and I very much, yeah, I heard so much product stuff in there. I mean some stuff that might now end up in a growth team as well, that sort of thing. It feels like some of that happened, you talked about the speed to value and that value creation, what a roadmap is, I would hope, a tool that helps us get to value and maybe communicate the different, the ordering or the sequencing or the possibly even the timing maybe of that value creation. How do you see that working in an early stage organisation?
Andy Budd:
I'm conflicted with this answer. I know that your whole shtick is talking roadmaps. And I think roadmaps are really good to a certain level, but they can also be problematic. And so I think there's a level of granularity that I think is really useful here. When people think roadmaps, they often immediately jump to features. And features are important, don't get me wrong. Like, you know, founders have this desire to add more capability to their products. And the capability comes in the form of features. Oh, our competitors allow you to do X, I need to do X on our platform. I wouldn't be called if our platform allowed you to do Y. These sort of features are like the additional tools in a Swiss Army knife. Now one of the problems is adding more and more features in a product, it becomes harder to use any single feature. And also if these features are not holistic, it becomes more difficult to talk about the features. Now Swiss army nice have got a great shtick, because they've kind of positioned it as a multi tool. Most startups don't to be positioned as a multi-tool. They want to have a really, really good framing and positioning. And so I think you can just keep throwing features on the roadmap and all of them make sense and all of them deliver great capabilities, but you can start to lose the kind of the vision and the journey and the shape of the product. So that's one thing to bear in mind. But the other thing, and this is going back to something you said a second ago, which is growth teams. Like if all you have are feature teams building new capabilities, who is responsible for allowing the users who are currently using the platform to discover the capabilities you already have? And so what I tend to advise from really early stages is you have kind of two mindsets. You have a feature/capability team, that are building new value into the product, but you have a growth team that are allowing the existing value to bubble up. And the things that you do on that existing value to bubble up, they can appear on a roadmap, but they're often the kind of things that don't sit on a roadmap very well. Or they're often things that gonna get sort of jumped over by new features and new capabilities. And so I kind of think you need to have sort of a multistream mindset. You got to have the features because founders and the executive teams are always gonna wanna add new capability. But if that's the only stream of work you have, a lot of the important value discovery work gets missed. And so this is why I think a feature team is a team that either sits off the main roadmap or have their own roadmap or really aren't even roadmap focused, they are outcomes focused. So you have a kind of a separate kind of like growth team that like we're not shipping features, we're not shipping from a roadmap, we are tasked to deliver this area of growth. We need to improve acquisition by 3%, we need to speed onboarding by 20%, we need to increase daily active use by, you know, 30%. All of these things. And you are solving these problems and in the process of solving these problems, you come up with hypotheses and the hypothesis may be, well let's try a tour, let's improve our drip onboarding email campaign. Let's try and make sure that the value that we are delivering is front and centre. Now some of this might end up becoming a feature that an engineering team needs to build, but you are putting that kind of, that sort of buffer in the way. So you're just not seeing things as feature, feature, feature, feature, feature. You are seeing things as problem solving, hypothesis driven stuff. And so I think having these two teams, one that is feature roadmap driven, one that is problem solving to access existing value, I think is a really, really useful model.
Phil Hornby:
Interesting, 'cause I would argue that feature team should still be working through a roadmap full of problems to solve and needles to move and minimising the features on there.
Andy Budd:
No, but this is the point here. You are absolutely right, but it doesn't happen. And I don't think you can change that overnight. And so what I'm suggesting is you have a small little side team that have the ability to manoeuvre in a way that doesn't destroy the leadership's desire to have a roadmap that they are controlling and they are shipping. Like if you are working in a feature factory, you are not overnight gonna say, hey, we are gonna move to a different model. But what you can do is you can carve out a smaller number of people and say, this smaller number of people have got a specific remit, where they can work in that way. Now ideally this becomes a strategy because ideally that small little value extraction team get better and better and better. And you start see them moving the needle, and then the leadership team go, well why are this team doing so well and that team aren't? It's like, well because that team is outcome focused rather than out like output focused. And slowly you can build that culture, but I don't think you can do it overnight. I've never seen anyone that have been able to kind of say to a whole bunch of founders, stop giving me features and start giving me problems.
Phil Hornby:
Yeah. it is the perpetual challenge. And yes, you often you have to disagree and commit then ship some of those features at the very minimum to build the trust that one you can ship, once you can ship, you can start to work up, you've got the trust to ship, you can start to work on the trust of now we can start to actually maybe bring things to the table that are from that broad problem space. But yeah it is a perpetual challenge and I can see that almost Trojan horse strategy working quite well of, oh, we've put this small team over here that can show what good looks like.
Andy Budd:
And also arguably it's a military strategy. I mean, again, I hate using military analogies, but a lot of leaders kind of like them, you know, that kind of small independent team are like a Navy SEAL team. With a Navy SEAL team, you don't tell them what to do, you give them the problem, you create a model of the space and you let them solve that problem. But you still have the inventory, you still have the tank division, you still have the major battle units that are being directed by the leadership and the leadership need to do that. But having a separate team of people that can work independently allows you to have this kind of two tier system. And so I think the best approach is to have, like I say, people shipping value, people solving problems. And I think the feedback and the frustration a lot of product teams get is they only want to do one in a world where both of those are necessary and actually the bigger team are the infantry. They're on the ground kind of troops team. And so yeah, I think it's just a pragmatic approach to a philosophical kind of challenge that we all have.
Phil Hornby:
Although I'm slightly disappointed we're both British, we're talking about the Navy seals, not the SAS but you know. We may have a roadmap there. And I think you kind of started alluding to there to a purpose and that purpose being around focusing on delivering value, but maybe being a little more feature oriented where versus when we're working on the problem and growth oriented, it might be moving too fast for a roadmap. Would that be a fair as a fair assessment of what you were trying to say there?
Andy Budd:
Not so much. I mean there is an element of speed, but there is also an element of kind of shape. I mean I dunno, you probably are aware of the Kano model? And the Kano model, it has sort of, you know, the kind of the core kind of performance driven improvements also has these delighters, these small little things that can actually have an outsize impact. Now these delighters are kind of things that designers will often petition for. Like we want to have a beautiful button animation, we want to have a lovely, you know, audio interactive element. We want to have a really, really smooth onboarding flow. Like these are the kind of the things that chocolate's in the pillow, the handwritten note at the, you know, the hotel cleaner leaves on your bed around what the weather's gonna be like the next day. Like these are all things that can have a massive effect on experience. That can actually make your stay in a hotel to be a wonderful stay. However, if you are going down a list of features in a roadmap and you are doing a Moscow kind of, you know, or you're doing any kind of prioritisation process, these are the things that are not gonna be at the top of the list. You know, again, founders, engineers, product managers are often gonna be pushing for new capabilities. And so I guess what I'm suggesting, is that you need to have a multi-tier like betting strategy, whereas you know, you have a, you know, you have a certain part of your time allocated to delivery of these obvious new capability features, but you also have a certain amount of time carved out for things that would not make the grade in a traditional roadmap. When you are looking at kind of like, you know, our bet on the impact and the, you know, all these kind of things, but which are, you know, harder to measure. But which actually deliver a huge amount of value. Like, you know, if you are a founder and you are trying to decide, well should we improve our email drip campaign for onboarding or should we add this brand new feature? If it's an either or, you're gonna say, well we're gonna need to add this one new feature because one of the people that our sales team talked to wanted this and our competitors, you know, blah blah blah, blah, blah. And so all of these smaller things start taking a back seat. But you need the resource to do that because it doesn't matter if you've got all these new features. If people aren't discovering, if they're not getting onboard, if they're not activating. And so it really is around dividing your attention and your resources in a way that isn't just one dimensional. And so, yeah, like, you know, we can do our, kind of clever sorting method on our roadmap, but we should also have a separate team that has a little bit more flexibility that can do things a little bit differently.
Phil Hornby:
I'd advocate, I absolutely with you, I'm not necessarily convinced about the separate team, but then I'm used to a product managers being zooming up and down and looking at those different layers. Like I remember when I started product, making those commercial decisions, like maybe improving a drip campaign was classically what I would get involved in. And I would make a marketing choice over writing a feature, as many times as I chose a feature over something else. Because success of the products not about adding features, but I think that craft has changed a little bit in the last 15 years.
Andy Budd:
Here's why I would advocate like, again, 'cause I think you've gotta decide why you are making decision. As a product manager for your quality of life, for your fun. Of course you wanna do it all, you wanna do the big six month, you know, version two, knock it out of the park features. And you wanna do the fun small little illustrative things that are gonna make a, you know, potentially make an interesting change. You wanna do it all. But that's sort of kind of selfish. And also I think if you're in a small company, you can kind of do a little bit of everything, but first off, we have a problem, like you said, of going up and down the stack. Context switching is really difficult. Context switching is a killer of productivity. If I'm having to think really big one day and really small than next or really big in one meeting, and really small the next. Like we lose a level of performance. And so you want to have different people, I think looking at different levels of scale on your product, you know. I know plenty of designers and plenty of product managers who are really good at leaning heavily into the lifestyle, the problem space of their customers that bathe in customer discovery, that are really good at understanding like where the product needs to be in a year's time, in two years time, in three years time, you know, building that vision. That's a thing they're really, really good at, they love to do, but they might not be the best people of doing AB testing. They might be not the best people of writing microcopy. They might not be the best people of putting something out that's really, really scrappy and messy because they are perfectionists. And so I think you need to have different teams that work at different scales. This is also why, going back to the example like the Navy SEAL team versus the, you know, the armoured military division. Like the armoured military division. You get them moving and they're moving and they're really good at doing that. They're really good at shifting resources and, you know, moving a certain way, but they're not designed and they're not staffed with people who are small and flexible. And so I think we want to be able to do it all. But I think that hubris and eGroup prevents us, I don't know too many people that are great at thinking big picture and also can roll at their arms and get into the day-to-day analytics. I don't know that many people, engineering teams who can make high performance, high quality code that can deal with billions of concurrent hits and also at the same time knock something up really, really quickly and messy to get it out, to test it, and be willing to not push it through the same level of engineering rigour because that is not what they're trained to do. So you need that high quality feature, future focused team that are around performance and quality and deep thinking. And you need the scrappy, messy, early stage kind of mindset. And you might be lucky and you might be able to find that in a single team that's very rare. And this is why we have, you know, different layers in the product stack. This is why we have separate growth teams. You know, this is why like most product teams don't have copywriters and marketers and SEO people and you know, multivariate testing and you know, and all that kind of stuff on your team. And so what you tend to find is you tend to slowly build out different teams that have got different skills and capabilities that are looking at different parts of the journey. And like I say, it's spread betting, you know, it's a difference. You know, it's a difference between, you know, you... I'm sorry, this is maybe a little bit too much of an analogy, but like if you are running a retirement fund for let's say postal workers in Canada, You want 90% of your portfolio to be safe as houses. It'll be in gold, it'll be in Gilt, it'll be in the S&P 500, You'll put it somewhere safe. You might want five or 10% of that. As in VC, in high risk, high reward investments. This is exactly the same mentality. You as a product leader, you as a VP of product, a CPO, you need to take an investment portfolio strategy, and you need to be with different teams, with different levels of risk, different levels of speed, so that you have the right people in the right seats. And so yeah, that's my view there.
Phil Hornby:
I mean I'm very much hearing a McKinsey three horizons essentially overlay there like that typically puts into three levels of kind of you at your growth, your core business and your genuine new business areas. And that's 10, 20 and 70% for example of that spread betting.
Andy Budd:
I Mean, you know, you kind of invoked the kind of the devil of McKinsey, I need to kind of cross myself for something here to banish the spirits. Like that is not the way I would necessarily put it. So this is the key 'cause I think it's really easy to see this in one dimensional thinking. Like I believe in now next and future thinking, which is probably similar to the McKinsey kind of like three, what do they call it, the three horizons, you know, I think it's useful as any leader to be thinking about what are we doing now and you know, over the next six weeks. What are we doing in the next three months? What are we doing in the next two or three years? And so horizons are one way of slicing things, but you can be, if you are running in a sprint mode where you're doing two week sprints, you can be delivering features in that model. You know, what are the features we're delivering now? What are the features we're delivering next? What are the features we're delivering in the future? But you can also be thinking around separately, we've already got all these features, we're not delivering new capacity, what can we do to help our users get that capacity out? And so I don't think it's as clear cut as like, you know, a timeframe. I think it's a mode of thinking. I think it's around, like I said, you know, delivering new capabilities, allowing people to find the existing capabilities easier.
Phil Hornby:
Yeah, but I think I've just spotted a possibly an interpretation of the three horizons that is not necessarily always the right way of looking at it. So you've turned those three horizons as time horizons, it's actually about focus. So one is about growth, it's kind of about growing your... It's optimising your core business so that as you call it growth. Another one is what they call growth, but it's actually about where do we add... It's the areas where we're winning new business. So kind of that could be the adding the new features. We can be working on these concurrently and paying off concurrently. With the speed of business today, the stuff in horizon three, the genuine new business, often has a habit of paying off even faster than the core business stuff because we're slowed down by tech debts and things like that. Whereas doing something new, and scrappy so often can pay off even faster. So we can be working on them all right now. But there's maybe some payoff timelines that vary.
Andy Budd:
But that's the point I'm talking about. If you are adding new capabilities, the timeline payoff will be in the future necessarily. Whereas you are allowing people to access the existing capabilities better. The value delivery is a little bit nearer. But again, like I do think when you look at the McKinsey stuff, it is usually considering a series of S-curves and you are looking at like, you know, the current growth curve we want at the moment is gonna be levelling out. What is the next trend we need to be surfing, what is a trend after that? And so I think it is a really useful planning tool, but I don't wanna get mixed up with this idea of value delivery, value extraction. And look, you know, it might be a model that works for me, it might be a model that works for some of your other listeners. It might not be a model that kind of works for you. But like I say, I want to have product leaders thinking more around spread betting and having different teams working on different types of problem, some of them delivering features, some of them solving problems. Than having a one size fits all mentality. And I guess that's sort of ultimately what I'm trying to get at.
Phil Hornby:
I mean I love the clarification there of value delivering and value extraction. I think bring really brings it all home to what you were just talking about there. So yeah, I love it. How do we get our teams aligned on those different threads of work? How do we communicate and align the direction of trial for those different threads of work?
Andy Budd:
I mean, it shouldn't be difficult. I mean I think the first thing is that, you know, you have team structures, you know, you have, you know, this is, you know, this team is focused on solving these kind of problems for these kind of users. We're delivering value, we're delivering new capabilities. When you're going off and doing discovery work, you're trying to figure out what our product doesn't do, that should do in the future. What is the most useful thing that we can be building next in order to deliver new value, yada yada yada, competitive analysis, like all these kind of things. And the team is focused on the vision of the product. You know, it is more of a vision driven thing. Like where are we heading? You know, a roadmap is basically a flag in the sand that says, this is where we're heading, this is where the product is heading. And you hire the right kind of people around that. You hire people who are user centred. You hire people who, you know, who are wanting to solve the bigger problem of, you know, helping the users solve their problem, you know, and the features and functions that allow them to do that. And you know, it is messaging from the leadership team. Each team has its remit. Each team is trying to solve a particular kind of problem for users, deliver that kind of value, yada yada yada. And then you hire a separate group of people who I'd like said, like the growth . And their job isn't to create new value. Their job is to allow that value extraction easier. And so their job is like, these are the three or four metrics that we're optimising for. We are optimising for speed of onboarding, you know, delivery of value over time. You know, this is our north star metric or this is a metric we're optimising for. And we are not giving you a roadmap to, you know, to ship from. We are giving you the autonomy to decide what do you need to do in weekly sprints in order to iterate towards that goal. And so you need much more independent thinkers, you need much more, you know, experimental thinkers. You have a hypothesis, you know, driven approach to these things. And so it's just assembling the right people on the right team. But like I say, you know, you are inoculating that smaller growth team from the bigger drumbeat of the feature factory because they're taken out of that loop of the feature factory and they're focused on yeah, like bringing all of those key growth elements down. So it really is just kind of like each team has the right messaging, each team has the right leadership, each team has the right manifesto or remit. It's a pretty straightforward thing to do really. It's just kind of basic management skills I'd say.
Phil Hornby:
I wish basic management skills were more commonplace then. Just like common sense is uncommon sense in most places.
Andy Budd:
But like I say, I guess what I'm saying is like there's a structural element to it, but within an organisation, you have different structures that support different behaviours. And you have leaders of each team that are given a remit around how their team operates and why it might be different from another team. And then you're just really clear, you know, in the same way as like, as I said, like you're managing an inflammatory division. You'd manage it differently from how you would manage a Navy SEAL or an SAS team, you know. And you just have to realise that you need a different mix of skills and each one of those skills has a different remit. And the kind of work that the SAS team has to do is very different from the kind of work that the air force or the, you know, the infantry or whatever has to do. So yeah, it's not as difficult with them. I mean, you know, most of the big tech companies have a growth team and have a effectively a feature delivery team. You know, if you look at Netflix, Netflix have a massive growth team and that growth team is a mix of product managers and engineers and designers, but their remit is focused on growth. It's not focused on feature delivery. And there's a little bit of grey area because some of the stuff that happens in growth might end up being a feature and vice versa. And there's always going to be a border that gets contested. But like, here's the other thing to move us off of this because I think we maybe got bogged down a little bit in a particular kind of thread, but the other reason why I think this thinking is important, like I often think into growing sort of companies, there becomes a point where there's a battle between product and marketing. It can also happen between product and sales, but it's less so. I think product and marketing is often a really, really challenging dividing line. Because if you are a product person, your understanding is that you own the whole of the product experience. And that product experience arguably starts from the marketing website, you know, the .com, the main domain name, and then it goes through onboarding, activation all the way through the lifecycle to, you know, kind of unsubscribing. And I think most product managers see that. Like we own this space. And a lot of the time product managers see marketing as everything that happens before people coming into the product. And so there's social media marketing and there's, you know, above the line advertising, yada, yada, yada. However, increasingly a lot of marketers see themselves as product marketers. They see themselves as we are not just driving people to the site, but we are owning the content on the site. And actually we're owning the onboarding process. We're owning the activation process. And actually once you're activated, we're owning the messaging and also we're owning the email kind of onboarding flow that kind of tells you what you're doing. And also, hey, you are thinking of unsubscribing, we're gonna own parts of the unsubscribing flow because we own the messaging and we're gonna offer you an offer that kind of removes that desire. So it suddenly gets really messy. And then what happens is there's a power struggle, the CMO versus the CPO. And in some organisations, particularly tech companies, the CPO wins because that is the modelling tech companies, the more traditional companies, the CMO wins. And in many, many companies a truce happens in this kind of like weird kind of borderland space, which can be really, really problematic. One of the reasons this happens often is because as product people, we work in a very different schedule. Like we work from a roadmap that might have been planned six months ahead. And then marketing comes says, hey Phil, look, this is really important. We've got an event happening two weeks time and we really need you to bump this thing up to the top of your list. And you're like, well we can't do that 'cause it's gonna mess up our entire programme. But you do it 'cause you wanna be a good person. And then next week the same thing happens, and next week same thing happens. Marketing people work at a fundamentally different pace. They're thinking often two weeks ahead, not two years ahead. And often they don't have resource and so they're relying on your resource. That starts to get really, really stressy. And so then marketing start delivering their own resource. And they start arguing, well we'll own the website. And we'll actually like, we'll have our own marketers and our own designers and yada yada yada. And so this battle for control gets really, really problematic. And one of the best ways I've seen to solve that is you put a third team in there, and that third team is the growth team. And that growth team arguably sits in the middle of product and marketing and it seconds people from both. So you will have in that growth team, you will have a bunch of product teams with engineers, front end, backend, product managers, yada yada yada. But you will also have some marketers, some copywriters, some marketing designers. And that growth team has a remit which is separate from marketing, separate from acquisition and separate from value delivery that kind of sits in that middle and grows and grows and grows and becomes its own thing. And so that is the emergence of the process that I see a lot of companies go down. If they can't solve that battle between products and marketing, they build this separate team that kind of harmoniously sort of interweaves the two.
Phil Hornby:
It's interesting 'cause I consider that interweaving to be product management's entire aison d'etre.
Andy Budd:
And marketers will say exactly the same. If you go to any marketing course, marketers will tell you about the three Ps of the four Ps of the five Ps. Marketers will tell you as a marketer, my job is product, my job is positioning, my job is pricing.
Phil Hornby:
Well I consider product management to be marketers. That's maybe where it comes in. People miss, if you look at what product managers really do, or should be doing, it's strategic marketing. Just basically nobody does strategic marketing anymore. They get taught at a university and then it disappears in the marketing domain.
Andy Budd:
But you're right. And this is why I think this intermingling is important. Because a lot of the really, really best product managers do stuff that could be confused with marketing. A lot of the really best marketers do stuff that could be confused with product management. And unless you have that kind of like DMZ, that kind of safe zone in the middle, which is growth where both of those groups can live harmoniously with their skills that overlap, but aren't impacting the bits that they don't overlap, then you have a really nice balance. If you don't have that space in the middle of growth, then it becomes a power play, where either the VP has a best relationship with the CEO and the investors or the CMO has the best relationship with the investors. Well maybe the CMO worked at Amazon and they've got more power or maybe the CPO actually used to work at and it becomes a horrible, horrible mess. And you can't solve this through power plays alone. And so it has to be a structural solution. And I think the best structural solution I've seen is the creation of growth teams that sit in the middle of both of those and create a third buffer zone where you can actually have the best of both worlds.
Phil Hornby:
Yeah, you see, I guess I've seen a different model that I quite like where essentially I think of it as, there are two teams, there's a product team, i.e. the product development and design team with product management sitting in that team. And product management sitting with a bridge into then what I call a go to market team, where I actually think of the product marketer as almost the broad equivalent in go to market as the designer is on development. And so that ultimately we're trying. There's different ways of solving it and it working better in different places. But I agree there's a need to find a bridge that means that people don't step on each others toes so much.
Andy Budd:
And I think some of this is kind of like naming conventions. I mean, I think early stages of a startup, go to market team, sorry, excuse me, makes sense. I think in the early stages of a startup go to market team makes sense. But if you are a 10-year-old company, you've already gone to market, you know, it kind of doesn't make sense anymore. Like, you know, you are not going to market now you are in the market. And so I think the growth team is not discipline focused, it's outcome focused. You know, what is our remit? Our remit is growth. What is our remit? Our remit is delivering features. What is or functionality? What is our remit? Our remit is driving users to consider our product. And so, but yeah, think it is largely kind of language, but I prefer the framing of growth. But like I say, you know, I think there's a battle and I think all the product managers I know are well within their rights to say we should own this. But ironically all of the marketers I know that are good are also well within their rights. And if we don't address the core overlap, then we've got problems.
Phil Hornby:
Well it's quite interesting the timing that you talked about. 'Cause maybe it's because I have a B2B skew in my history, but the marketers usually were working on the much longer timelines than even the product people. And so we found that actually we'd have a demand a year's time that we had to meet. 'Cause they were playing towards CES or MWC or whatever it was. And so those were fixed dates, we'd still fight because we didn't want to be given a constraint of a date. Although I'm actually quite a believer that if there's an externally driven date, you work to it, right? You can't change the world. Well not without delivering anything anyway.
Andy Budd:
But I think this is the thing though, like, you know, I dunno if you are aware of the sort of the Stewart brand concept of shearing layers, you know, within an organisation there are different areas that are working at different kind of speeds. And I think you're right in a, you know, in a small, early say startup, which is where I mostly am, there's no point thinking about what will be happening next year. 'Cause you might not even be in existence next year. And so I think marketing in an early startup is very opportunistic. But I would also say that in a very large company, there is gonna be a team of people in the marketing team that are very opportunistic as well. A new story breaks, a competitor goes under, a crisis happens. And they will want to very, very quickly get ahead of that and utilise that, you know, a Google indexing changes, you know, something happens with, you know, kind of, you know, pay per click. You know, there are always these sort of shocks that need to be dealt with really, really quickly. And these shocks can completely destabilise a beautifully well planned out kind of roadmap. And, you know, if you are as a product team, you know, driving towards a particular launch date on a thing and the marketing team says, hey look, we need to do this thing right away. We've got an offer, you know, for our CEO to go onto "Forbes," and he said that, you know, or she said that we are going to deliver this sort of feature and we need to kind of deliver it, then you need to, you know, you need to bump it up. But you're absolutely right in larger companies, you know, these marketing plans can also be many, many years in the making. And so, you know, the point being that different teams work at different speeds. And when those shearing lays interact, they cause friction. And, you know, and you've gotta be aware of those areas of friction and you can't be precious around it. And you can't be protective. You've gotta figure out ways in which you can manage that natural friction. And you can't just go, well look, you know, we've got our roadmap and you know, we are not gonna kind of deliver on, you know, on what you are asking because you know, that's gonna mess up our plan and our KPIs, our OKRs, you know, this is a difficult thing. Like OKRs are great, but you know, if you've got a silo team over here that are working to set of OKRs and some from marketing says, well need you to do X and it doesn't match the OKRs, then you get that kind of friction. So it is complicated.
Phil Hornby:
Yeah, I think that's what you could conclude that about everything in business life and definitely product. We've lightly touched on road mapping I think Andy, but I think I'm gonna pull us back to, I guess my core question I always like to kind of finish with. If you had to distil your philosophy on road mapping into one or two sentences and maybe we can put a growth overlay onto that, what would it be?
Andy Budd:
I mean, again, I think road mapping is too blunt a tool for me to answer that question. And you probably see it as this beautifully nuanced thing, but road mapping is basically a sequencing of activities, hopefully in order to drive towards some kind of, you know, vision of an outcome. But it's arguably a delivery mechanism. And there are multiple ways of doing a delivery mechanism. I guess the point I'm making is how do you decide what to deliver and when? And so the way I look at, it is much more through the lenses of the acquisition funnel, you know, pirate metrics and it's much more through the lens of kind of loops and funnels and much more through the lens of growth. And so however you decide to do your roadmap, however you decide to divide up your work and give it to different teams, I think you need to structure the teams differently. And I think you need to have different levels of fidelity to give to different teams. And so I don't think a one size roadmap fits all. You know, I do think of it like a portfolio, an investment portfolio. And you know, I think you can have a single, you know, one team or five or 10 teams that are delivering functionality from a core roadmap. And I think you can have three or four teams that are delivering from a different plan, a different format, et cetera, et cetera, et cetera. But really it's all around coordinating where is the best place, whereas the right place to put effort and why are you putting effort? You're putting effort to grow, you're putting effort to beat the competition, you're putting in effort to make sure you secure that next round of funding. Because you want to have lots of amazing jobs, you wanna have lots of, you know, happy customers, you wanna have lots of happy staff members. And so like in a weird kind of way, I see the roadmap itself as a means to an end, not an end in itself. And it's a handy McGuffin for managing more challenging questions around value and resource allocation. And I think if you use roadmaps in a two dimensional way, you miss out a whole bunch of nuance, which I think is really important. If my whole investment portfolio was okay, my investment portfolio is which stocks that are traded on the, you know, the indexes should I buy, then you are only limiting yourself to kind of a certain class of investment. If you are looking at the solving problems. And, you know, so arguably maybe, you know. The thing that I think is really problematic is people jumping too quickly from problem to solution. And I think what a roadmap is, is a store of perceived solutions. You know, we are gonna do this, this, this, and this. And what happens is you put it on the roadmap and then you forget it. You kind of expect somebody else to deliver it. And you've already decided this solution's gonna work. And so you're probably not gonna look back and check it. And even if you do, you know, you've shipped, it's gone out, it's in the roadmap for six months, it gets delivered, you've moved on. And so there's very little learning opportunity once something's gone on a roadmap. And also often gets untethered from the person that initiated it and the problem it solved. I'm much more interested in having a store of problems Forget the roadmaps. I want an organisation to have a backlog of problems, you know, a problem backlog rather than a roadmap. And every quarter the leadership team look at that problem back up and go, what are the major problems we need to solve? And then come up with a bunch of hypothesis about how we might want to solve these. And, you know, again, a roadmap item is usually one of a number of hypothesis, but again, it gets decoupled from all the other hypothesis. And the only way to keep all those hypothesis together is by coupling them with a problem, you know, a problem store. And this isn't just with kind of product delivery, this is also with how you run your business, however you run the business, you're gonna have a bunch of problems. You're gonna have problems around the inefficiency of certain divisions. You have problems around performance of team members. You have problems around all kinds of things. Like if you just immediately jump to the solution, then it might be the wrong thing. So yeah, a constant store problems. And every quarter, have we solved that problem? No. What did we try, we tried this, that and the other. Did it work? No, didn't work. Okay. What are the other hypothesis? We can test? Bang, bang, bang. And you only remove that problem from your problem backlog once it gets solved. And so yeah, I think you have this sort of dual thing, a list of problems, your hypothesis of how you're gonna solve them. And the hypotheses of how you're gonna solve them are the roadmap. But it's not set in stone. It's not, well we've delivered this and everything's fine. You need to constantly keep bringing it back to that core problem.
Phil Hornby:
I think I broadly agree. I mean, frankly, my roadmaps are covered in problems, not in even the solutions until I get really close term these days. That's also not something that every organisation is mature enough to deal.
Andy Budd:
But it's also because I think the model of a roadmap, I think it's too linear. And I think you are right to try and fill your roadmap with problems, not solutions, but that's not, you know, like a to-do list is a list of things to do. You know, it's not a series of problems that you are constantly looking at. It's a series of things you check off. And I think most roadmaps become a series of things you check off. And even if you try and hack it to stop people from checking them off, there's a desire to check them off. And so you need to have something else that isn't a series of things you check off in a to-do list sort of mental model. And so I think, yeah, I mean it is a nuanced thing. It's a philosophical thing, but I just think there is a different class of problem or space that you hold these things. That is separate from a roadmap, that is mapped to this roadmap and constantly map back and forth. And the ironic thing is, I think actually most product managers are that thing, you know, and what they have is they have a whole bunch of problems in their mind. So they're constantly doing that manually, but it's invisible because it's in your head. And people are constantly annoyed with you because why are you asking this? We just need to ship this thing. And so I think weirdly product managers are filling in the gap. Because we are not effectively managing problems well. And we are giving them to you that you then try and shove them down this little pipe that we call a roadmap. That isn't quite fit for the job.
Phil Hornby:
It's an interesting place to leave it Andy. So it'd been a pleasure having you here and I love conversations like this 'cause they're challenging some preconceptions. You know, the channel might be called "Talking Roadmaps," but I'm actually completely happy to throw away roadmaps the day we can get all of our teams aligned and going in the same direction and delivering value consistently. It's just a tool in that space that helps us do that. So as always like to end, Andy, with just an opportunity for you to pitch yourself, pitch your services, how people can find you, how you can help them.
Andy Budd:
Well look, like I said, I do a few things. I'm a VC. If you're running a European based early stage pre-seed seed startup and you want to get funding, come and drop me a line. I'm just Andy at, you know, andybudd.com. I work for a company called Seedcamp and yeah, always loving to talk to early stage founders. I also do private advisory work. So if you are a founder or a design or product leader that is like having challenges with some of this stuff, then also reach out. But the main thing I'd say is go buy the book. You know, if you go to andybudd.com/book. Or you just go to Amazon, "The Growth Equation," you know, it is a book that I think product leaders will get a lot of value out of. But also it's one of those books that maybe you give to your founder if you were in an early stage startup and help them kind of along that journey. But yeah, and if you buy the book and you like it, go and give it a nice quote on Amazon. So yeah. Thank you very much.
Phil Hornby:
Thanks Andy, it's been a pleasure having you here.
Andy Budd:
Likewise.
