Should your roadmap be purposeful and strategic? | Steven Haines

In episode 60 of Talking Roadmaps, Phil Hornby interviews Steven Haines, who shares his insights on creating purposeful and strategic roadmaps. They discuss how roadmaps are more than feature lists—they are tools to align with broader business goals and strategies. Steven emphasizes the need for transparency between executives and product teams, guiding strategic intent with data-driven decisions. He also delves into the role of financial literacy in product management, highlighting the importance of business acumen in driving product success.

Steven Is the founder and CEO of Sequent Learning Networks, an internationally positioned training and organisational advisory services firm focusing on product management excellence. He’s also the founder of The Business Acumen Institute, a training company that builds business and leadership skills.

Before he started Sequent, he worked in various product leadership, financial, and operational roles at AT&T.  While at AT&T, he worked on a corporate task force that benchmarked dozens of other firms’ business practices and also served as a member of AT&T’s global leadership development program review board.  He was also one of the founding fathers of the CRM business unit at Oracle during the famous ‘dot-com’ era in Silicon Valley.

For ten years, he contributed to the start-up world by serving as a mentor to The Founder Institute, the world’s largest entrepreneur training and start-up launch program. The Founder Institute helps aspiring founders across the globe to build enduring technology companies.  Additionally, and for two years, he served as a member of the board of directors of The Product Development and Management Association.

Steven received his BS in Management Science and Organizational Behavior from Binghamton University, and an MBA in Financial Management from the Lubin School of Business at Pace University.  Steven is based in New York City. 

Steven Haines’ ideas and books have contributed to corporate growth strategies for more than two decades. His enthusiasm and focus have contributed to many best-selling business books that include: 

  • The Product Manager’s Desk Reference (3e)

  • The Product Manager’s Survival Guide (2e)

  • How to Create a Business Case 

  • Product Strategy & Roadmapping 

  • The Business Acumen Handbook 

  • Business Acumen for Project Managers

  • Leading Product Management 

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).

In the next episode we are talking to Alex Brodsky, he’s CEO & Founder @ Iteright. So watch out for Season 1 - Episode 61!

  • Steven Haines:
    And I think that the opportunity for executives if you are listening, is to be more transparent and stop being fluffy about what you think your strategic intent is, and collaborate with the product people so that they're carrying things out. And stop making them into project managers who are just doing projects and help them to be product people who are business people who are gonna help you fulfil your strategy.

    Phil Hornby:
    Welcome to "Talking Roadmaps", the channel where we talk about everything roadmapping, the good, the bad, and the ugly. Today I'm joined by Steven Haines. Steven, introduce yourself.

    Steven Haines:
    Well, I'm Steven Haines. I am the founder of a company called Sequent Learning Networks and another company called Business Acumen Institute. Been doing this for about 20 years, helping companies across industries and around the world. I am a corporate finance guy by trade. I worked in AT&T and in the early part of my career and my boss's bosses made me go into product management. Which was really was not something that I was on my radar screen, but turned into the best career I could've ever had. So, happy to join in today, and we'd love to share some thoughts with you guys.

    Phil Hornby:
    If you're enjoying the channel, subscribe, hit the bell and give us a like. Yeah, I mean and obviously, just for a little context, Steven has recently just published a book that talks about road mapping, so I'm sure there's gonna be some of the content and thoughts from that that's gonna come up. Let's start out with the really softball question then. What's the purpose of a roadmap?

    Steven Haines:
    So if you got in your car and you needed to go someplace, you'd say, "I have to go from here to there." And so a roadmap by association in the business world is how you go from here to there. So it begs the question of what's here and what's there. And so what's here is based on your current state and how you got to there. So there's an element of past and present. What's there tends to be referred to in business as a vision. But I think that even that term becomes, pardon the expression, blurry. And the reason is many people aren't imbued with this natural sense of, I can envision what the future should be. And from another standpoint, the way in which any person in business, product or otherwise, their perspective or their vantage point is determined by perhaps their level in an organisation or their experience. So if you're sort of a beginning person and somebody says, "What's your vision?" It's like you can only see 12 inches in front of you. If you're a senior person, you're much higher, you have more experience and you have a vantage points from which you can see a broader landscape. But in a lot of the sort of current events, people just talk about vision is some thing that you're aiming for, but it's not clear what it is. Sometimes I say it's like hallucination because I don't think that people really, really get it. And if you really tested a 100 product people or even down to POs, their version of vision would be insufficient in my mind. So go back to what a roadmap is. It's a way to get from here to there in business or the business of a product, you have to figure out where do you wanna be in the world I mean in terms of fulfilling specific customer needs, being competitive or achieving competitive advantage pertaining market share or the kinds of things that are associated with business goals that are measurable. Okay, so in a roadmap, when you're driving down the highway or in your case the motorway, there are markers. What are the markers? You have markers that are mile posts and signs and things that make sure that you're keeping on your path. Well, in a lot of cases in business, we don't have the markers which could be like metrics or deliverables. And so if you decompose some of these elements and you really understand them at sort of at a lower level, and then you're able to pull back the perspectives you have in terms of where you are versus where you wanna be become clearer. So it's not the object, which a lot of people say, "I sort of want to just fill out the roadmap and say what features am I gonna make?" It's something that's a lot more complicated that takes a huge amount of experience in order for people to really figure out what a product or strategy or technical or other roadmap. And again, I have some definitions of what's the composition of a roadmap that may go beyond features and functionality.

    Phil Hornby:
    Love it. And so you've already started to speak to how it links into vision and to strategy. And if I remember correctly, you'd like to talk about a guidance statement, maybe you could unpack that sort of principle and how that links into a roadmap then.

    Steven Haines:
    If you've ever listened to a CEO or a CFO in a stock market call like an analyst's call, right? Which you have anybody can dial into these things. Executives provide guidance to analysts. Here's where we're going, here's why we're going there. And the reason is we're trying to offer confidence for our investors. So what's the corollary to that? Well, if you're a business person, whether a product person or otherwise, you need to inspire confidence in the minds of the people who are your bosses and your peers and others who are the people with whom you collaborate. And so somebody's got to offer that guidance and I think it's critical to come up with statements that have facts and data behind them so that they're credible or believable or whatever else you need to have so that people understand what you're trying to do and why.

    Phil Hornby:
    And so you started, I mean, I guess investors could factor into this as well. We've got that guidance statement which is essentially a form of vision of where we're going, where we're taking, having that confidence that it's the right place to go I guess, and that's kind of informing our roadmap. But who's looking at it? Who's the audience?

    Steven Haines:
    Well, I think it depends. There are so many different audiences, and again, it sort of depends on your level or perhaps your vantage point. I always, I like to look at sort of, you have internal stakeholders and potentially external stakeholders. And internal stakeholders could be like your technical community who sort of needs some help. And that's a very, very collaborative type of an exercise to creating sort of a STRAP deck for your bosses to offer them confidence that you know where you're taking your products business. Something that you might need to sort of go to the top of the house where you need to inspire confidence by the c-suite to say, here's where the people in this product line are intending to take the business. And it's synchronised or aligned with this strategic intent of the organisation or your corporate pillars, whatever you wanna call them, so that there's again, confidence up and down the line. And it sort of goes with this idea that when you're thinking about strategy, in strategic planning there are sort of this cascading effect. So the executives in the company set the tone, they set intent, they have broad goals. Those are the things that they may be offering the street for the investors. If you have a multi-divisional complicated organisation, you may have business units or divisions or things like that where those entities have to become the interpreters of what the senior executives are. So they're sort of a communication and a clarification from the top of the house to the middle. And then we have to go down to where most of the product folks work. And that is within a product line or something like that. And a product line needs to have in kind projects and programmes and things to do for their products that help the division and ultimately the company to achieve its intent. And what I find if I'm doing a STRAP programme with any company, people in product have no clue. This happened this week where I said, so tell me a little bit about what your company's strategic intent is and how does the work that you're doing fit with the context of that? Nobody, but nobody could explain it. And I said, "Well, just go on your company's internal website." And they couldn't find anything. And I was talking to the one of the guys who was sort of my champion and I said, "You know, there's gotta be more clarity. There's gotta be more bit more transparency from the top of the house to provide the people who are expected to carry this stuff out. But, so I get into my little ranty state and it makes me mad when the senior executives of these big companies, they have economists and researchers and all of this stuff that helps them put their strategic plans together and they don't share it with people who are the workers. And they have to teach them, here's how you do competitive analysis and here's how you do. They're not teaching them the stuff that has already been done. Why should executives cause a disconnect? And then sort of throw the product guys under the bus when they're not performing. And to me that's a sin. And I think that the opportunity for executives, if you are listening is to be more transparent and stop being fluffy about what you think your strategic intent is and collaborate with the product people so that they're carrying things out and stop making them into project managers who are just doing projects and help them to be product people who are business people who are gonna help you fulfil your strategy. That to me, I think is important. And we may be going off on a zone 'cause it's not your roadmappy thing, but roadmaps are just artefacts that get produced in response to strategic intent.

    Phil Hornby:
    So I completely agree. I mean so many times I've run training courses very similar to yourself for many years. And often as I'm doing the strategy module, I'd say to the people in the room, "Do you know your strategy? Can you express it? Or at least a vision or the mission." And universally I'd get a blank stare from around the room. Usually there's a leader in the corner of the room who looks aghast. It's like, "But we have an operating plan, you should all know this." At which point I give them an action for the next week to make sure everybody knows it.

    Steven Haines:
    Well, you know it's interesting because, I have this thing I write about and I talk about. Like, "Alright, it's June, you have to start putting your spreadsheets together for next year." "Nope, I don't like those numbers. Make those numbers this way." So everybody's handing in their spreadsheets and by November, the budgets are all loaded up and that's your STRAP plan and that's BS, that is not a STRAP, that's an operating plan for an organisation. What I think is also important, I believe that portfolio strategy, product portfolio strategy which also starts at the top of the house is vital. And when an executive team is sort of looking at their portfolio of products and services and whatever else they have, alright, they tend to divide them into these buckets, this piles of money. And loosely they could be stuff like the R in R&D, You know, just sort of like the the researchy things and the experiments and stuff like that. Some of the innovative projects. then they would have, well I have projects I've already funded, like how are they doing, have projects that are in like going to market. So there are products that are in various states of development, and then I have a whole portfolio of stuff that's in the marketplace. And that there is money being allocated to sort of growth oriented products and sort of mature products and things like that. It is not clear even to the product people that level of transparency of, where are you spending the money and why? And it's almost like you have two different societies inside of the corporate framework. The executives and the the workers. And I think if you really want product management to be a successful part of the organisation, there's gotta be a deeper connection again between the top of the house and the people who are carrying these things out. And the people who are carrying out these plans to come up with in kind goals, the goals say, "Okay, so here's what I'm aiming for." The strategies are, here are the steps we could take, but we have another step that is often ignored. And that is how do you take a thing that is in your strategy, okay? And make it into an investible item, all right? An investible initiative. And an investible initiative requires more work. It requires resources and timing and things like that, which is a business case. And one of the things that is sorely, sorely missing in product line strategy are business cases for initiatives. So I find that completely unacceptable. And the other part that goes along with that is, how do we audit or check in to see whether or not those investible initiatives actually provide the return to the business. So my advocacy is for a sort of higher level perspective on how things are working and that the things that trickle down from that are tactical activities, maybe done by POs, maybe by BAs, or just maybe associate product manager types, okay. But from my point of view, the product manager or to sort of own that business or the senior product manager so that they can feel empowered and accountable for the delivery of results, alright. And we can go into whole conversation about job levelling if you want.

    Phil Hornby:
    I'm gonna agree. I mean there are obviously many different ways of doing that sort of justification of the business case, but ultimately the success of product is the successful of the business of their product. You know, it comes back to, are we making money? That is the final arbiter at the end of the day. That's the fuel that keeps our business going, that funds the next thing, that is the ultimate measure of success at least if we're in a profit making environment. If we're in a nonprofit making environment, then it might be that we at least break even and are delivering good somewhere else, but the money still needs to be there.

    Steven Haines:
    Well, there's another perspective on how product is in an organisation. Let's say you take a large telco, a large carrier. It could be a Vodafone or Verizon, any of these companies. They're a 100 billion dollar plus enterprises or whatever they are, right? They probably have hundreds if not a thousand or more product people, but those companies have market momentum. They send out bills every month, the money is coming in, all right? And so stewardship of a product is different in those environments. And the level of accountability and responsibility is also different. And that, some of the people who are at the sort of lower end of the spectrum in the employees in product, may not have what's necessary because they're just not not responsible for that level. If you get into smaller to middle-sized companies, there's a lot more visibility. So I have a lot of companies that, I mean there may be a $100, $150, $200 million manufacturers or software companies or whatever, product people are working much more closely with the president of the division or the CEO. There's a tighter bond because the path to market and the success of that $100 or $200, or the $300 million company is critical. So you get sort of corporate blurriness of roles and responsibilities the bigger the organisation and strategy and those investible things are decided at a much higher level.

    Phil Hornby:
    Yeah, that's a fair sort of perspective. And in terms of I guess the abstraction or how much influence an individual PM can have, I think they should still be caring about the profitability of their product.

    Steven Haines:
    Without a doubt, everything... Listen, every decision has a financial impact, end of story. And so if a product person doesn't get that, then they're already at a disadvantage. And I'll give you the example of this workshop I just did this past week and many of them were newer. They just didn't understand basic finance. They just didn't. And it's sort of like you can't be in a business role without thinking about money. So you're a 100% spot on. And as a former finance guy, it just aggravates me, you know? And listen, I run a couple of businesses. Heck, it's cash flow. You know, you check the bank a account every day, you see what's coming in, you see what's going out. How do I have to put my marketing activities into action. I mean, it's my money. Well when I used to coach my product people, I'd say, "Could you just pretend it's your money for a minute. Because the decisions you're asking me to make and the recommendations you're asking me to carry upstairs I'm not doing. And if you're not willing to bet your job and bonus on it, leave me alone. Get out of my office."

    Phil Hornby:
    Yeah, I mean I think we're seeing a little bit of the pendulum coming back to that kind of business angle at the moment. We lost it for a few years in product, but with the change to like cash, funding being a lot more expensive, that realisation and recognition of the business realities is coming home to roost for a lot of product people that have never had to care about it because they were in cash generating machines that didn't need to care about funding.

    Steven Haines:
    You know, in a lot of companies I work with, the product people, there's no visibility to even the sales mix or pricing, or revenue or even gross or contribution margin. They just don't have it. And when I try to find out what these executives are thinking of, well the accounting system is in tune for that and I will say, "Are you kidding me." How are you gonna understand product profitability? How can a product manager understand product profitability? Isn't there some way to do sort of a proforma, sort of do the math that at least allows them to look at this stuff. When I worked at Oracle, there was garbage for finance and I used to go to the finance guys and they'd say, I want for all the product codes, I want an Excel dump every month and I will parse the data. They would take revenue and allocate it to regions. There's no rhyme or reason for any of that. I have no idea what the hell they do now 'cause it's 20 years later, but to me you gotta be curious enough. Go talk to the finance guys, alright. Gotta find something. It's interesting and I wanna go back to this whole roadmap thing, right? Because if you wanna know where you've been and where you are, one of your key mile marker is the money that you make. How many do you sell? How many transactions, how many units? It's volume times price is revenue. You have to have the formula.

    Phil Hornby:
    I mean, talking about that gathering data, I remember literally my last rule, I had the same issue, I came in, we had none of that data. I tasked one of my team to go off and get it and he did a really skunk works approach of getting SAP exports, then transforming it all in Excel, getting it to a point where we had data for one product, just one. But then showing that to the rest of the leadership team, it's like they suddenly saw their eyes open. It's like, "We can start making decisions, we now are gaining an understanding. Can you do that for everything else?" Now now we had the mandate to go and bug finance to do it properly.

    Steven Haines:
    A couple of years ago I was working with the company in Finland and we were doing a leader level meeting. So all the executives in the company were in the meeting, we're teaching them about how to stand up a product organisation. And so one of the things from an assessment we did had to do with sort of we call it data availability. Okay, what data is available and are you gonna make available to the product people? And they didn't have financial data and the CFO was in the room and we were talking about how are we gonna do that? And he didn't even understand it until then. And the project that they chose to undertake for the first six months post-program was to adjust the chart of accounts in the general ledger so that they could align and create product line profit and loss statements. That was music to my ears, okay? It's not impossible. Then again, there are some very large companies that have sort of merged their way to size. One particular company in the healthcare medical product space had seven different accounting systems. So it was because of all the mergers. So they never integrated systemically. And so it was so subtle, what a shortsighted thing to talk about corporate messes and it shortchange the product people 'cause they couldn't get the data they needed.

    Phil Hornby:
    But I mean this all feels very much in the large corporate context, but the same issues I've come across in the startup world. Like not being able to get hold of the data. The vision being held in the founder's head and not being prepared to share it with their teams and then they can't start kicking the product people. It's like, well how are they supposed to know what chart to set, the direction to say the roadmap to create if they don't know where the goal is, what we're trying to achieve.

    Steven Haines:
    A lot of startup guys are not operators and they're not financial. So they have the shiny object, they got the money and they're running for the wall. And it's sort of in many cases, many of them have sort of impact the professional product management because it caused the product managers to go and just build features get stuff done. Which I guess is okay if you're running a startup, but at some point you have to start to look at a maturity model and say, to be a bigger company, scaling doesn't mean selling more stuff to more people. Scaling also means create a corporate infrastructure that allows for this. And listen, it's not that all of them fall into that trap. There are many, many successful organisations. But especially in software and tech, I think it's a particular challenge.

    Phil Hornby:
    So I'm gonna switch gears a little bit bringing us back to roadmaps. You talked about different levels and different kind of content in an answer earlier. Maybe you could unpack to that. What do you typically put on a roadmap for some of those different groups at different levels?

    Steven Haines:
    I have a bunch of things up the left side of the page. One says functionality features, user experience, design styles and packaging, performance and capacity, safety security regulatory, platform and technology and international. So I have one, two, three, four, five, six, seven, eight, nine elements that could go onto a roadmap.

    Phil Hornby:
    So these are the left, so these are almost like swim lanes.

    Steven Haines:
    These would be your swim lanes, okay. So every one of these. So this is sort of view two, I call it the purposeful one. I'll send you the things, but the first column says strategic goals, what are we trying to achieve? The second column says, year one or period one, work plan, activity, stories and context, alright? And then metrics. So the main idea is, what are the things you wanna do and then how are you gonna sort of get your team together around them. So for instance, you can go backwards, but if you say, there are some platform investments that I wanna be able to make that will enable me to develop a higher level of competitive functionality and the features that fall out of that get put into sort of a sort of a Gantt chart format, that sort of looks like, you can call it your feature roadmap. But it has to be hooked to something. If you're in a scaling environment and you have performance and latency and other crappy issues, what are the things you're gonna do to support and build that could speed up your response times so that you can expand or do other things. Again, there's sort of a base, some place where you're starting and then steps that you wanna take going forward. So when you talk about levels, the levels mean what am I gonna do with my dev guys so that they're bought into the things they have to do so they can put their project budgets and tracking mechanisms together to the point where I have to maybe package my stuff from my bosses, alright? Maybe I wanna show them how I intend to execute on the business case on this initiative that I put forth, okay? Then there could be another one or an higher level one. Here's what we're gonna talk to the higher level executives to give them the guidance to show them sort of our past, present and future, okay? But for me, you sort of need to decompose things into broad product business elements, which are those sort of those nine things, okay? Without that it, all you're doing is feature planning and that's a huge trap because to what end are you trying to do it? Now mind you, if let's say you have a list, you have a backlog of some kind, maybe some you have bugs that you have to fix. So you have to put resources on this stuff, especially if it's service impacting or customer impacting or things like that. And then you have sort of like, you sort of work down your list of priorities of things that could provide additional value or competitive advantage to other things which are on everybody's wishlist that it's just not worth doing, right? Like leave us alone. And so we have to be sort of the vetters of the list, okay? But it's gotta be based on what are you trying to achieve for whom and when, for what investment and what return do I provide to the business, and ultimately am I gonna provide value to a customer that's gonna cause them to stay with us or choose us over other options, which is the essence of business.

    Phil Hornby:
    Love that one. I always phrase product management has been about delivering customer and business value at scale. So it's kind of, we've gotta do it repeatedly and gaining that multiple customers coming to us, gaining that value then means that they're happy to pay us, which means that we gain the value.

    Steven Haines:
    Or there are, listen. There are any number of SaaS applications that exist out there and doing adjustments and changes is a constant, it's just a machine. But I'll give you an example. I'm a QuickBooks for business user, have been for years. I'm also a Microsoft Office user. Crap that gets introduced shows me they have no idea about who I am, what I'm trying to do. And every time they change the user interface, they don't tell me, alright? So they're so internally focused on their own stuff, "Oh, we're gonna make it better for anybody else." But you know something, they're not making it better. They're actually making my life worse because I have to figure out what the hell they were talking about, what they did and where the reports are now and where the customer file is and why this other crap about payroll and all this other stuff that I don't wanna know anything about, okay. So why don't you make a version for me and stop jacking up my prices because you're adding value to somebody else or soothing the ego of your CEO. And I'm sorry, there's a lot of crap out there, alright? A lot of crappy interfaces and a lot of crappy software that just give me the core functionality that I need. And so everybody can go, everybody's doing their roadmaps and doing things dutifully, but are you doing it for the purpose of a person who actually cares? So it tells me they don't understand their market segments and their customers, they don't understand what customers value in terms of their time. But think about, listen. Anybody who's watching or listening to this as a user of anything, okay. You could have a cable box in your house and the latency rate because your pipes are crappy, do you have to wait 15 seconds to change the channel? Or if you go into a teller machine in a bank and the authentication process is taking too long, does anybody care?

    Phil Hornby:
    But I guess one of the arguments could be made that you and me maybe as, I'm both also QuickBooks user, those changes, they may be optimising for a different segment that are their primary target segment perhaps.

    Steven Haines:
    Then make a version for me and stop raising my rates. I'm sure there are no intuit product people like, listen. They've got a very profitable franchise. I can't fault the Intuit corporations for any of this stuff, but I think sometimes you're so big that you sort of do the common denominator for a broad market area and let people pick and choose what they want, but just keep charging them. But every time I call them every year that they raise my rates, I'm saying, I want a lower rate and they won't do it, so.

    Phil Hornby:
    How do you typically visualise your roadmap then? And is it that simple sort of tabular format or is there's something else that you like to use?

    Steven Haines:
    Well, first of all tabular formats are just for mental models, okay. It's just sets a pattern for thinking. So I'm a big visual person. When I worked at Oracle we had a conference room, we called it the War Room, alright? And we had floor to ceiling whiteboards in the gigantic room. It was just outside my office off the elevator bank where all the product and the tech people were. It was a very strategic thing and there was always food there which is even better. But it allowed us a workspace to show interconnections. And we were in the CRM business and we had multiple groups. So we had all the interaction centre technology stuff which was mine, we had sales, marketing, service automation. So you had four different groups working together. You know when you were on the release train, you sort of had to develop, test and integrate, develop, test and integrate by the way we were iterating before iterating was popular. But that's sort of how we just sort of visualised what we did and then everybody could see what we're doing and then we could say, "Okay, so now we have to go do trade offs." Right? Because we said we were gonna do this last week, but what gonna do this? So we didn't have a start up, we had a sit down, right? Again, we did the same things that were logical on a business that had to sort of go, that had to iterate, okay. And so I think that tho those were important. So I like visual tools. There are some of the software companies, I'm not gonna name them, who I think they sell the idea of feature mapping as part of their roadmaps. I've actually reached out to all of them to ask them to teach me what their software does so I could talk about it in my classes, but they don't want to do it because they're also competitive because they're trying to train product managers on their stuff.

    Phil Hornby:
    Yeah, I've experienced something similar and I'm also a big fan of visual. Like there's a floor to ceiling whiteboard just over there.

    Steven Haines:
    I have a whiteboard right over here. It doesn't matter whether we're looking at marking planning or anything like that. It's sort of a, it's a brain space. This is also just FYI on my commentary on virtual working. You know, you can have as many mirror boards or whatever the hell you wanna use for collaboration when people are working miles apart. But there's nothing like being face to face when you're putting a roadmap together.

    Phil Hornby:
    There's definitely something to be said for that high bandwidth communication you get together. I'm a big fan of remote working, but there are different phases of work and you use the right interaction model depending on what phase of work you're in.

    Steven Haines:
    We've been a virtual business for six, seven years now. And to be honest, we still go to the office, right? 'Cause we have a whiteboard and we can plan things out. I mean, anyway, that's sort of where it is. But in terms of the visual tools, I think that they are profoundly important. The thing I think is also important though, is consistency in the visuals that you're gonna show to people. If you did sort of a Google images search on product roadmap, you'd have like a million different images of what people represent on their roadmaps. So what I talk about with my clients is, if you're doing a STRAP plan or a STRAP deck or a business case deck, whatever the sort of standard deliverable or documents are, make sure that they are consistent across the enterprise, okay? Which means if you have a specific road mapping tool, whatever it is, make sure people know what to expect. Down to fonts, down to colours, down to format. I'm a little bit of a perfectionist on these things, but I think that they're really important in establishing professionalism and expectations and the credibility of the product management community who are often subject to influences in society organisation that may question their value.

    Phil Hornby:
    Yeah, well I similarly, I remember creating documents following the external brand guidelines for my companies that were internal documents because as far as I'm concerned, part of our job as product is to sell to the rest of the organisation. So representing ourselves well. And I remember one of my former brand sort of team members coming to me and saying, can I take this example document and show it to this other team because your internal documents look better than their proposals going to clients. It's about, it again comes back to that professionalism. Let's take you down another avenue. What do you consider is best practise when it comes to road mapping?

    Steven Haines:
    I think the practise of strategic planning for products and product lines is where everything starts. I am an advocate for this... It's like I think about the STRAP deck, okay? I think I have a sort of this visual model, whether I put in the book, it's sort of what I do, but I ask people to ask and answer five questions. Where we've been, where are we now, where are we going, how are we gonna get there and how are we gonna know? Okay, that is what I would say your best practise framework, okay? So the thing about it is, do you have the data to support where you've been and where you are now, and how do you break that data into smaller pieces? Okay, so I've done it in the book to sort of just point out what those key things are in terms of whether it's the products business or down to service and support or operations, and of the other parts of the business infrastructure that supports the product's business counts toward the where we have been and where we're now. So you can't pivot to the future unless you know what those things are, because the future is a reflection of those components, right? You just hold the mirror up and it's the same stuff. Because if you can envision what the P&Lis gonna look like, or what your sort of your products business information dashboard is gonna look like, six months from now or a year from now, what are you gonna do to move the needle? So you think about the dashboard as the instrumentation for the product's business. It's another best practise I think is sorely missing inside of organisations. And the reason they don't do it is, they're not paying enough attention to current product performance. So they get stuck in this mire of, it's sort of like, again, their roadmap things become very, very tactical without an anchor from the past, the baseline from what you've come and what you're ultimately trying to do to impact the performance and results and financials of the business. So it's not, the practise is doing the work. A practise is doing like a practitioner, like a doctor or a lawyer or a pilot, their practitioners. So what's a practise is doing something enough time is where you get really good at it. So how good are you at really doing customer and market and competitive analysis? Those analytical techniques contribute to your understanding of what's going on and why. So if you suck at market analysis, then your strategies are gonna suck because they're not gonna have an anchor. If you don't understand the numbers that got you there, then how are we gonna put the numbers together for the future? So you have to be the practitioner of the business, so you understand again, not only the product, all the functional components, operation, service, support, finance, even HR and staffing and talent, okay? Because part of what you have to do, your resource plan isn't just a bunch of engineers that you're putting into a budget. A resource plan can include sales and marketing and service and support and all the other people who have to help you be in business in the future. So if you're not a good business practitioner, you can call anything you want, all right? And that's just window dressing. You have to go into the details and understand the business at the gut level, with data and facts and trails of evidence the way a lawyer would do.

    Phil Hornby:
    Love it. Now that almost feels like we're getting onto the answer for my next question, which is getting to the last two hardball questions. If you had to distil your philosophy on road mapping down to one or two sentences, what would it be?

    Steven Haines:
    Facts and data. You've got to have the facts and the data collected at the speed of the market or at the speed of the business so that you can make appropriate decisions as to what you can do on how you have to stop doing certain things, continue to do things that make sense and do things that weren't in the plan, okay. So it's a business strategist's perspective.

    Phil Hornby:
    Tell us about your biggest road mapping failure.

    Steven Haines:
    My first product management job, I was in AT&T, I inherited a office communication system. So in the day AT&T had a small office system called Merlin. Merlin had about 50% market share in the US. Somebody made a deal with Ricoh in Japan to manufacture and distribute a Japanese version of that product that I inherited, including the tech transfer agreement and everything else. So I was asked to put a plan together. I worked with my technical community and everything else. I was very, very new, and I came up with a plan. It looked roadmap-ish, but I didn't understand enough about the marketplace. I didn't understand enough about the business. And so I did something in a vacuum and I was a kid, I was really young and I should have known better and I didn't have any coaching or mentoring to help me. So I had sort of this plan that was doomed to fail. So then I start going to Japan and I start visiting offices and working with the Ricoh sales force and going to the factories and just trying to get the gestalt of how things are working. And what I came away with is, AT&T had no business being in Japan, number one, we didn't understand the market at all. I have no idea who came up with this idea. I could never even find the business case. The only thing I had was a tech transfer agreement and some guarantee forecast and things like that. And so I ended up having, It was really weird. I wrote a business case to get out of a joint venture that we had no business being in, which got me a double level promotion. So my roadmap failure was weird. I wanna give you an example of what happened. I took on, we called the things that were, you would say called a telephone, they were called terminals. So the terminal had a lot of functionality in their very of bus really incredible tech. Had a display, alright? And in the US version it had a single line display. It was barely used for any, it was more, more like functional programming of the terminal. In Japan, the way the people, they call them the salarymen, the way they worked. So when you went to an office, you'd see four desks sort of butted up together in a pod but only one terminal. And the Panasonics and the Toshibas and the Hitachis had two and four sort of lined displays. And things like sort of an identifiable ring pattern so that if the phone rang, the programming was employee would know that the call was for them and they had other sort of caller information, which is now ubiquitous on every device that you own. But when I came back, so I didn't know anything about the display other than the fact that I just left it off the roadmap because I just thought, "Just the same, whatever it is." Until I realised that, which was really like one of those, really. How did anybody miss that one? And I didn't know anything about telecom, I just was a sort of doing anthropology. I was just watching people work, right? Which is also one of my key life lessons in life. Like, unless you can actually be with the customer and live with the customer and understand who they are, what they're trying to do in the environment at which you work, every other piece of thing that you work on that's a PowerPoint presentation, has no value until you've actually, you can walk in their shoes.

    Phil Hornby:
    That's a great truth bomb on there, Steven. So always like to end with the opportunity for you to give your pitch, how people can get hold of you, where they can find you, how you can help them.

    Steven Haines:
    Well, I run two companies, Sequent Learning Network, sequentlearning.com, and another one called Business Acumen Institute, business-acumen.com. My goal is to help people be better business people, whether you're a product manager or a person who works in engineering or any other function to be a better business person. So we do diagnostics, we do training. Everything we do is customised. We work with big complicated companies around the world. And so my email, you can just use my sequent email, or just visit the website and I'd give you my phone number, but I'd probably get a lot of bad calls. This is a good book really, I have to tell you. And it's only 74 pages long filled with all kinds of helpful goodies.

    Phil Hornby:
    And I'm partway through it myself, hence, I knew about that little guidance statement shift. But great, Steven it's been an absolute pleasure having you here today. Thanks very much for your time.

    Steven Haines:
    Thank you so much.

Phil Hornby

Co-host of Talking Roadmaps

Passionate product professional. Helping entrepreneurial product teams to be successful. Coach. Trainer. Facilitator.

https://www.linkedin.com/in/philhornby/
Next
Next

Can a roadmap answer all your questions? | Cliff Hazell