Last month we ran a workshop with a name we couldn’t quite put on the public event listing. “What the F**k is Impact” is a provocative title — but as presenter JJ Monester made clear from the opening minute, it’s an honest one. Because when you really start pulling at the thread of what impact means, how it’s formed, and how it’s measured, you quickly discover that almost no one has a satisfying answer. And that’s exactly why it’s worth a room full of product people spending an evening on it.
Setting the scene
JJ comes at this topic from an interesting vantage point. He works at The Conversation — a not-for-profit news media organisation where academics write evidence-based content, and editors translate it into something the rest of us can actually read. With over 220,000 articles published across 11 global editions, approaching 6 billion reads, and around 110,000 academics published, The Conversation is genuinely trying to democratise knowledge at scale.
But being a not-for-profit means operating with two goals instead of one. Most organisations can point to a North Star metric — user retention, revenue growth, conversion — and orient the whole team around it. Not-for-profits have to balance that commercial reality against a harder question: are we actually making a positive difference in the world?
JJ framed it this way: imagine riding a horse with impact on one rein and revenue on the other. Pull too hard in either direction and you crash. The skill — and the challenge — is the balance.
That balance became very concrete when JJ was tasked with improving member retention for The Conversation’s university partnerships. Universities from around the world had completely different structures, priorities, and ways of measuring the value of their research. In the UK, the Research Education Framework ties how universities report research impact directly to tens of billions of dollars in public funding. Impact, it turns out, isn’t just a feel-good concept for these institutions — it’s a bottom-line metric they have to prove to keep the lights on.
That discovery sent JJ deep down a rabbit hole. And rather than keep the rabbit hole to himself, he built a workshop around it.
The activity: mapping impact for a fake company
After a grounding video from the Impact Management Platform — a UN and OECD-backed initiative to create shared language around impact for sustainable development — groups were handed a fictional company and a big sheet of paper.
The task: map out inputs, outputs, business activities, and the value being created or eroded. Two questions anchored it: What’s the traditional North Star metric for this business? And: What could impact actually look like here?
Two groups shared back at the end of the session.
BulkBreed Energy — a fictional smart energy and green optimisation platform with around $380M in revenue and engineering teams across Berlin and Austin — started where most companies do: revenue. But as the group worked through the mapping exercise, a richer picture emerged. Reduced waste. Increased renewable energy adoption. Lower electricity bills for consumers. Reduced pollution. But also: potential unemployment in mining towns as traditional energy sources wind down. Their overall impact statement landed somewhere honest and ambitious — better for people, better for customers, better for the world — while acknowledging that “better” isn’t always straightforward.
Atlas Freight Systems — a fictional SaaS platform for global logistics optimisation — found that complexity quickly multiplied. Their North Star was a universal freight platform that delivers everything on time and on budget. Clean enough. But once they started mapping, the picture got messy in interesting ways. Inputs covered workforce on both the tech and freight sides, physical materials, and time. Activities included navigating relationships with governing bodies across multiple jurisdictions. Outputs were primarily their SaaS platform — with secondary outputs including freight movement itself, and all the waste that comes with it.
The impact layer was where things got genuinely uncomfortable in the best way. Atlas could create positive environmental outcomes. Or significant negative ones. Spoiled freight, missed shipments, delayed supply chains — each one a potential value-eroding event. The group landed on customer satisfaction and environmental value creation as key measures, while honestly acknowledging that almost every impact dimension could tip either way depending on execution.
The question to take home
JJ closed with a provocation worth sitting with.
In 1970, Bhutan decided not to measure national progress by GDP alone. They created Gross National Happiness — nine categories, full measurement infrastructure, national surveys — and have used it as a legitimate alternative metric ever since.
If an entire country can build a framework for something as complex and contested as happiness, what’s stopping your organisation from getting more intentional about impact?
The ask wasn’t grand. JJ put it simply: if you leave this session and ask yourself just one question you weren’t asking before — What is my product doing in the wider world? Who does it influence? What value is it creating? — then the night was a success.
Thanks to JJ for bringing the rabbit hole to us. Resources from the session can be found in the reading.
Thank you to our sponsors!!
Thank you Revity & Amplitude for teaming up to support this community!
Amplitude: We help companies build better products.
We help companies unlock the power of their products.
Revity helps startups, scaleups and established organisations deliver product-led quality software outcomes.
We partner with businesses to build high-performing teams, uplift engineering capability, and deliver product outcomes that last beyond the project. From applied AI and mobile apps to global expansion and customer lifecycle platforms, we focus on practical, scalable solutions that drive business value. At Revity, we don’t just deliver projects, we empower teams to learn by doing, so organisations grow stronger with every engagement
What a February 2025 talk on digital sustainability revealed about the hidden environmental cost of the tools we build and use every day.
When we talk about sustainability in tech circles, the conversation usually drifts toward electric vehicles, renewable energy and corporate net-zero pledges. Rarely do we turn the lens on ourselves – on the Jira boards we manage, the SaaS platforms we ship and the AI queries we fire off a dozen times a day.
That’s exactly what our digital sustainability advocate KB (Katherine) Buzza set out to change at the Product Anonymous Melbourne meetup, armed with a copy of Tom Greenwood’s Sustainable Web Design and a lot of inconvenient data.
The message? Sustainability isn’t just an environmental issue. It’s a product problem – and product people are uniquely positioned to fix it.
The Sector We Don’t Talk About
Most of us are vaguely aware that data centers use energy. Few of us know the scale.
Research from Ericsson and university partners found that the information and communication technology (ICT) sector consumed around 4% of global electricity in 2020, accounting for 1.4% of global greenhouse gas emissions. That figure is projected to climb to 15% of global electricity by 2030 – driven by AI, surging data center demand and the sheer proliferation of devices.
A recent study from the French research organisation GreenIT.fr breaks down where that footprint actually lives:
60% comes from end-user devices – manufacturing, purchasing and running our phones, computers and (perhaps surprisingly) televisions
20% from networks
20% from data centers
The manufacturing and embodied carbon of our hardware is the single biggest lever. Not the cloud. Not the server. The device sitting on your desk.
This reframes the conversation entirely. The greenest phone isn’t the one with the best energy-efficiency rating – it’s the one you didn’t buy.
“The Cloud Is Material and Computation Is Metabolic”
Cloud anthropologist Stephen Gonzalez put it plainly: the language around cloud services has obscured the physical reality of information storage, creating a fantasy of infinite, weightless abundance.
There are no fluffy cumulus clouds holding your data. There are warehouses full of humming servers, cooled by enormous quantities of water, powered by electricity that may or may not come from renewable sources – often located thousands of kilometres from the users they serve.
Every query, every file upload, every forgotten duplicate in your S3 bucket has a material cost.
The AI Question Nobody Wants to Answer
Generative AI has supercharged this problem – and the companies building it aren’t being transparent about it.
None of the major generative AI providers have published clear environmental commitments. In their absence, a Washington Post study offered a useful proxy: generating a 100-word response via ChatGPT consumes approximately 500ml of water and the equivalent energy of leaving an LED light on for an hour.
That’s per query.
For teams that have integrated AI into their daily workflows – code review, documentation, customer support, sprint planning – the cumulative impact is worth thinking about seriously.
Big Tech’s Report Card
The talk took a candid look at four of the most common tech suppliers in the product world:
Microsoft Azure makes bold commitments – carbon negative by 2030, removing all historical emissions by 2050. But a former senior sustainability lead recently left the company citing a fundamental contradiction: Microsoft’s custom cloud work for fossil fuel companies is actively enabling greater extraction, potentially exceeding any carbon savings the company achieves elsewhere. Opening three new data centers a week compounds the challenge.
OpenAI has made no meaningful environmental commitments. Full stop.
AWS takes a more measured approach – fewer sweeping claims, but genuinely useful resources for builders who want to make greener architectural choices. Worth exploring if you’re making infrastructure decisions.
Atlassian earns the gold star. Their sustainability strategy document (cheekily titled Don’t F** the Planet*) is transparent, detailed and backed by action – including paying employees to use green energy at home and building Atlassian Central in Sydney, set to be one of the tallest timber-framed buildings in the world.
The Green Software Foundation’s Six Principles
For teams ready to embed sustainability into their practice, the Green Software Foundation offers a practical framework:
Carbon efficiency – emit the least greenhouse gases possible for any given task
Energy efficiency – use the least energy to perform that task
Carbon awareness – schedule compute-intensive work when the grid is running on cleaner energy
Hardware efficiency – minimise embodied carbon by extending device lifespans and avoiding unnecessary hardware
Measurement – you can’t improve what you can’t measure
Climate commitments – understand the actual mechanism behind any carbon reduction claim, not just the marketing
These aren’t abstract ideals. They’re engineering and product decisions that most teams already make – just without sustainability as a criterion.
What Product Teams Can Do Right Now
Here’s where this becomes an action list, not just a lecture.
Hardware and E-waste
Extend device refresh cycles. Fight the instinct to push features that demand newer hardware.
Repair over replace – a new battery costs less than a new laptop, in every sense.
Dispose of E-waste responsibly. In Victoria, putting E-waste in landfill is illegal. Are your organisation’s policies keeping up?
Measure how much E-waste your organisation generates annually.
Data storage
Encourage a “digital spring clean” – delete what’s not needed, manage duplicates and archive rather than actively store stale data.
Audit dead customer accounts. They’re a security liability and an unnecessary load on your infrastructure.
Renewable energy
Ask whether your infrastructure runs on renewable energy. If you have a choice of cloud region, it’s worth factoring in.
Low-carbon design and development
Reuse and repurpose content and code rather than generating from scratch.
Choose efficient file formats.
Consider the environmental footprint of your coding language choices – there’s a real hierarchy and it matters at scale.
Ask where your data center is relative to your users. Proximity reduces latency and transmission energy.
Supplier interrogation
Before renewing contracts with major cloud or SaaS providers, ask about their environmental strategy. Request transparency on water and energy consumption. The question alone shifts incentives.
The Business Case Is Already There
This isn’t just good ethics – it’s good engineering.
Sustainable software tends to be efficient software: leaner, faster, cheaper to run and more resilient. The principles that reduce carbon footprint also reduce infrastructure costs, tighten security posture and improve development velocity.
Sustainability, framed correctly, is a performance enhancer.
Product managers and developers sit at the intersection of every decision that determines a product’s environmental impact – from the infrastructure it runs on, to the features that drive device obsolescence, to the AI tools baked into the workflow. That’s not a burden. That’s leverage.
The question isn’t whether the tech sector will need to confront its environmental footprint. It will. The question is whether product teams will lead that conversation – or be dragged into it.
KB (Katherine) Buzza’s career begun in marketing before embarking on a journey to discover how business can drive positive environmental and social change. Having worked across sectors, she has maintained a passion for sharing knowledge and climate positive solutions.
As a product manager for carbon account software company Climate Zero, she wants to keep expanding the conversation about sustainability in tech beyond data centres and decisions outside of our control.
Our Wonderful Host:
Chargefox is part of the AMS Group. Every day thousands of drivers charge their vehicle on the Chargefox network – the largest and fastest growing EV charging network in Australia. We’re owned and operated by the NRMA, RACV, RACQ, RAA, RAC and RACT. The same companies supporting drivers for over 100 years https://www.chargefox.com/
Kate Lanyon came to speak to us about the relationship between product folk and engineers and some of the areas that can create friction between us. She’s got some great tips and insights as to how to reduce this friction and help create working relationships that kick ass! Kate’s been an engineer for a long time and draws on her experiences of being that individual contributor and performing some of these sins herself – through to being a CTO and co-founder where she’s also led engineers and had to coach them in some of these areas.
Her most recent experience at a startup digs deep on this topic because if engineering and product aren’t in sync in this environment, then you’re not going to be successful. Start up land is a fight for survival. If you haven’t worked in a startup, startup is like the most extreme form of product development that you can have. A startup must find value, before the money runs out, and raise more money than exponentially find more value to raise exponentially more money. Even if your team is not fighting for survival, hopefully some of these tips will make your life easier.
Lastly, an important disclaimer to every story or generalization shared in this talk, it doesn’t do justice to the uniqueness of every individual. So do take these examples as an opportunity to be curious and ask more questions of those you work with.
So what do engineers do?
Kate’s definition of what engineers do every day is that they apply deep knowledge to solve complex problems. It takes a lot of learning to be a great engineer, learning from each other, learning at conferences, and they learn different things, programming languages, techniques, they have to learn the system that they’re working on. There is a whole lot of learning and deep knowledge that goes into being an engineer.
The day job involves a lot of complex problems to solve. And even though an engineer may have done a thing before, a lot of web development is just forms and websites and things right? Yet, every system is different and every system is constantly changing. Even a thing done yesterday, trying to do that thing again today, it’s gonna be slightly different. Things move so quickly, the world around us changes really quickly, and engineers have to keep up with it. Working in code, there is never one single way to do things, there’s many ways to do things. And a task is broken up into many layers with many decisions. So engineers are constantly making decisions.
“It’s not as simple as just like, hey, build this thing.”
It’s not a straight path forward – sometimes an engineer will get stuck. Several constraints will come together in a way that it’s not easy to see a way forward. This is when an engineer will go play a video game, go for a walk, or leave for the day and go to sleep and wake up at 2am with a huge burst of creativity and a way to solve the problem. As Kate shares from her own experience this can happen regularly, where the moment of distraction is the moment you come up with the solution.
Her other insight is that there’s something Pavlovian about coding. It’s having a plan of how something should work, writing that down, and then running it and seeing it work, or not work. And doing that multiple times an hour, the joy at the code running, in the test passing or the frustration when it doesn’t. That’s micro level but it’s constant in an engineer’s day. And it’s just again and again and again. Perhaps that description makes it sound bad, but it isn’t, it’s not bad. It just is what it is. Yet that’s important to explain to product folk who sometimes don’t understand that internal world of an engineer and that lived experience.
To summarise, engineers are always learning and researching. They’re always understanding the landscape and the system that they’re working in, and the constraints that they have to work with. They’re constantly making decisions and evaluating what they’re doing and the way forward. They have large leaps of creativity at times. And a continual evaluation of success. These are really useful skills in other things as well. These are the things that engineers are training their brains to do every day.
How to engage your engineers
To quote Marty Cagan “if you’re just using your engineers to code, you’re only getting half their value”. Why does he say that? Because the engineers are closest to the technology, closest to the breakthroughs and what is just now possible, thus they’re a great source of innovation. Kate adds to this definition that the skills learned today through coding, when put towards solving customer problems, as opposed to focusing just on delivering what they’re asked, then engineers can be a great contributor to finding the fastest path to value.
So how does this work? Marty lays out several ingredients to having an empowered engineering team. You need a product vision that is intended to attract and inspire these engineers and you need a product strategy to ensure that engineers are working on the most important problems. You also need team objectives to give the engineers a clear statement of the problem to solve and the outcomes to strive for. None of this should be new to a PM (product manager) but it’s certainly reassuring to hear from Kate that these tools are truly useful for all members of the team.
In addition, the PM and the product designer on the team provide the engineers with critical constraints regarding the business viability and the customer experience. User research and data science provide the engineers with key insights to factor into the problem solving. Then as a team, you can find a really effective path to value. In terms of working in your own teams, take a look at these ingredients and see if you can understand why the engineers on your team joined the company that you work for, why your team exists, and how your team measures success, you can start to have really good conversations with your engineers at a higher level than just what can or can’t be done. Instead you’re discussing how we can solve the customer problem.
As an example (see image above) here is everything that we can make in the system, right now, things are coming in and out of this circle all the time. The engineering team, ideally, is aware of those. Then there are the things that solve the most important customer problem, this is where the product team can frame this for the engineers. Now we’re working with two constraints. Then there are the things that the engineers know the customer can actually use, the product designer gives us these constraints. In addition to these myriad of inputs are also budget, deadlines etc. Ideally, together, we find the jam of the thing that we should be doing next. And at this moment empower your team of problem solvers to solve customer problems. Like what could go wrong with this right? Nothing could go wrong!!
Technical perfection
Now we might get to technical perfection – this is something to be aware of. It’s hard to see. Because it can look like things taking longer than you expect. There can be other reasons for that. But it’s important to be aware of why engineers gold plate things, or over engineer them. We are incentivized by our industry to do this. This will happen when your engineering team is more excited about solving the problem in a technical way, they’re more excited about the solution, rather than solving the customer problem.
This is a natural consequence of just being told what to do. “Build this thing”. This shifts the problem to how to write the code. As Kate has said, she’s felt this too, and has gotten excited and made that into a challenge for herself. However, the engineering industry also wants engineers to do this.They’’re rewarded and recognized by their peers, and the industry, if they do stuff that’s hard and challenging and interesting and new. It demonstrates mastery, if they make something that’s technically perfect, even if it doesn’t solve the customer problem. In Kate’s words – I can write a blog post about a thing that’s completely irrelevant, but it’s cool, technically. I’m having a bunch of people telling me how awesome I am.
How good an engineer is, technically, is how career progression is assessed. If one was to write something really simple that solves a really big customer problem, will a manager be impressed by that? Sometimes if they’re a good manager, but a lot of the time No. And since engineers just love learning, the new and the technically difficult is something that they’re just naturally attracted to. Editor note:This insight into how a product person can actually “trigger” this behavior when potentially the attempt to keep things simple by sharing less information to avoid this situation was an Aha moment!
Feedback cycle
To quote Brian Cantryll – he’s a CTO & co-founder at oxidecomputer – “Above all else, engineers wish to make useful things”. All the engineers where Kate works love this guy. Brian cares about the customer. He wants to build useful things. Thus, an engineer’s highest priority is to satisfy the customer through early and continuous delivery of valuable software. This is the first of the twelve Agile principles, ironically enough, written by a group of engineers! Engineers are capable of caring about the customer problem, but they have to be included in that conversation.
At this point though it’s worth talking about why that conversation might not be happening. One of the things that can go wrong in those discussions is whether or not the feedback or questions are perceived as criticism or analysis. Engineers are direct at times. Those skills that were mentioned earlier that engineers develop, the dark side of that is that they have an overdeveloped sense of critical thinking. That is not something that can easily be turned off, that Pavlovian response means that engineers’ brains are trained to try and find issues early. That’s how they get to that little moment of joy.
That is then reinforced constantly on any working day. An engineer cannot turn off their critical thinking. They can’t not say something, if someone just presents them with a solution. In Kate’s experience, she’s going to immediately see three issues with it. It’s just whether she tells them, and she can’t not do it. It would be like walking around and trying not to read billboards or street signs, the human (engineer) brain just does it. The reason it does it is because of the length of experience doing this job. The call out here from Kate, is not that you should take crap from engineers. Instead, when an engineer comes to you and it seems like negativity, maybe just take a second look and assume good intent. Is it criticism or analysis?
Is it badly phrased? Could they use some feedback about how to better phrase things? It can be very easy to experience the directness of engineers and their ability to find issues and holes and things as a personal attack. It’s not generally meant that way. Some people are assholes but for the most part it’s not meant that way. Thus, when your engineers come to you with problems or questions, you should feel free to work through that. Try asking them questions and engaging in your own curiosity, answer their questions as they’re trying to understand better what’s needed here and try to help them understand what you need from them. However, do work with your engineering leadership to give feedback on how to collaborate better if this is a clunky type of discussion despite your best efforts to engage in discussion, because you’re doing everyone a favor if you also encourage feedback and coaching in this area.
Trade-offs
I want to talk about trade offs – don’t try to actually interpret the picture above – it’s from a textbook. It highlights the system attributes and how they all interact with each other. The reason to show this is because when engineers say no, or they ask questions, this is what is in their head, but exponentially larger. Thus it’s up to you, the product manager, to figure out how deep you want to go into this. What questions do you ask now? Your engineering colleagues will be happy to explain it to you, if you’re willing to listen. It might not be that easy for them to express this in words (Editor note: a replay of some fascinating team chats where I’m sure we were talking cross purposes, because I, the PM, wasn’t actually being curious. And the person across from me was likely struggling to figure out how to explain this massive image in their mind to me!!). Generally, the criticism comes from trying to unpack all of this. There are limitations of the system, the conventions of the system, like the engineering principles of the company. Even something as simple as will this get past code review? Can this be done within the deadline? There’s a whole lot of calculations that are being done, that they’re not easy to articulate because of all of what’s oversimplified in the above image. As Kate begs, please do ask and be patient in the conversation to get to an answer.
Nonetheless there is something to be said for trusting your engineers to work through this thinking for you and leave them to weigh up all the constraints and come back to you with a good solution.
To circle back to the feedback part – suggested reading of the resource Radical Candor – to help with giving feedback. A couple of reflections from Kate, who found it a super useful resource to improve in this area, engineers are generally fine with challenging directly. We all (engineers and product alike) need to spend some more time caring personally to ensure that feedback is well received and given with the best intent! Because the main message from this book is that if you do provide feedback from a place of caring you can say almost anything. If you can establish a relationship with your engineers, where you’ve established that you care personally then you can give feedback. And in return, you as the PM can be open and receptive to feedback as well. Then the relationships and the team can be more productive. But it’s work. It’s definitely work that needs doing.
Flow
The best thing about being an engineer, in Kate’s opinion, is flow. Flow is a mental state, where it’s extreme comfort, extreme concentration, but it’s effortless. And everything falls away when you’re in it. It’s been studied in artists and athletes, But engineers can reach it too. It’s described as the secret to happiness. To get to this, there’s several ingredients, and you, product people, can help your engineers with those, and help them get to this moment, if you recognise their need for this and respect it. That’s how you can make a connection with your colleagues.
The different ingredients include whether or not an engineer has the ability to completely concentrate on a task. Are they in an environment where they have a block of time that they can get into work knowing they’re not going to be interrupted? Do they know what they’re actually trying to do? Do they have a clarity of goals in mind? Then if we go further, is the task an appropriate skill level for them? If it’s too easy, or too hard, they won’t be able to get into this state. They need to feel ownership over the task as well. You can find more in this Ted talk by Mihaly Csikszentmihalyi. This is definitely a way to connect with your engineers, if you can respect their flow time.
Another area to think about is how to help your engineering colleagues get their technical debt under control. Following on from float, technical debt makes it harder to get into flow. Because the system is muddy and terrible to work with. Technical debt as a term is kind of falling out of favor at the moment, to be replaced with other things like code health or things like that.
Kate’s preference is still the term technical debt, because from the perspective of “debt” the metaphor falls down. Technical debt seems like a loan to be repaid, and no one ever repays it. However, if you think of technical debt as a loan with interest, then it works. Technical debt is any code that’s more expensive than it should be, code one has to pay interest on. That interest is getting paid when you get delays from bugs or in not enabling your engineering team to reach flow and be productive. The way to handle technical debt is to spend time paying it down knowing you’ll never pay it off completely.
If not, that leads us to talk about rewrites. Rewrites are a bad place to be!! You do not want to be doing a rewrite. If you’re doing a rewrite your customers are not going to get any value during that time. These projects always take longer than you think. There are companies that have been really damaged by doing a rewrite, while their competitors have been able to keep going. And in some of those cases they’ve lost everything in that gap of time while the competition moves on.
Going back to that technical friction, rewrites are very attractive. It’s a new puzzle. It means an engineer is free from all the bad decisions that were made in the past, when one didn’t know any better. It’s a great way to learn, it’s going to look super impressive on a resume. However, you can avoid getting tempted by managing the tech debt. Thus tech debt needs to be a regular investment of time to pay down the growing interest. Marty Cagan says that product managers should just take 20 to 30% of their time off their roadmap/planning to manage tech debt, in conjunction with an engineering team always having a prioritized list of things they want to do with that time. Through regular maintenance, you can avoid the need for rewrites. You cannot necessarily avoid people asking for one – it’s always going to look intriguing. You, the product team, should be investing in not getting to the point where it’s needed, because having to halt all delivery of customer value is not going to look good for you as a product team!
Summary
What are the things to keep an eye out for as product folk to work so well with your engineers that you kick ass together?
Use your team of problem solvers to solve customer problems. Engineers need discovery and research time, asking them for stuff on the spot is going to result in them saying whatever comes into their mind at the time. If they have research time, then they can actually go away and prove it and improve their answer. Constraints are good so share them all as you’ll get a better solution.
Help engineers find flow. They produce their best work this way.
Have a discussion about technical debt, assigning time to regularly pay it down. Make sure it’s prioritised. Engineers shouldn’t just fix whatever shiny thing is in front of them, they should have a list of the most important things to fix. Avoid needing a complete rewrite!
A really good starting point in finding common ground between Product and Engineering is one of the twelve Agile principles (these were written by engineers after all) – “satisfy the customer”.
You can find other the slides, other good resources and books on Kate’s site.
Thanks again to Kate for all the fabulous insights and thoughtful suggestions for creating great working relationships with your engineering team! Thanks to Kogan for being our wonderful host.
Our speaker: Kate Lanyon, Engineering Manager at Fastmail, co-founder & former CTO of Eugene Labs will shared insights into the above. Kate has a led a varied career – going from full stack development, to mobile app development and back again before moving into senior leadership. She has worked with teams across many different domains including agencies, start ups and corporates. You can fund musings at her website.
Our host: Kogan.com is a pioneer of Australian eCommerce. We are a dynamic and rapidly growing business. Our team believes in using & building technology to improve the online shopping experience for our customers. We are pragmatic, intelligent, fast paced and driven by seeing our software shipped to production daily. The software we build – including www.kogan.com – is used by millions of customers. Check out our pride and joy https://devblog.kogan.com/ to learn more about us and how we deliver amazing products and software!
A panel of early-career product managers got refreshingly honest about breaking into the role, debunking the myths, and surviving the first 90 days.
There’s a version of product management that lives in LinkedIn posts and job descriptions — the PM as visionary, strategist, and “CEO of the product.” Then there’s the version that actually exists: messy, rewarding, full of questions you don’t know how to ask yet, and occasionally including a LinkedIn photo of your dog.
At a recent Product Anon event, a panel of practitioners at the beginning of their product careers sat down to talk through what it really looks like to get into PM — and what nobody tells you once you’re there. The conversation ranged from career pivots and 65-job-application marathons to the moment you realise you are absolutely not, in fact, the CEO of anything.
Here’s what they had to say.
The Winding Road In
None of the three panellists arrived at product management via a straight line. That, it turns out, is very much the norm.
Hugh Osbourne, who has been a product manager for around two years at a startup — where he also wears the hat of UI/UX designer — came from four years in design. His entry was less a deliberate pivot than an act of self-preservation. “I was sick of being told what to do,” he said, “which is a terrible place to be in a small startup working directly with a founder.” His solution was to push until the founder gave him the product manager title while he kept the design responsibilities too. The upside: “I got to tell myself what to do.”
Jane (Ryan) Card, an Associate Product Manager who spent a year at Delphi before moving on, came from a people and culture background — change management, learning and development, organisational transformation. What drove her towards product was a creeping sense of distance from the end user. “I felt really far removed from the customer,” she said. “I can say that my customers were employees, but I felt like something was missing.” Seeing colleagues do CX and innovation work was the tipping point. “That’s the shit that I want to be doing. That type of work is cool and fun and interesting.”
Heike Radlanski, now a product manager at Expert360, a talent-matching platform, came through digital marketing. She had stumbled into a product owner role within her marketing position and enjoyed it — but it was a career break that crystalised the decision. “After that, I was like, I need a job. I don’t want to go back to marketing. I think I want to go into product management.” What appealed was the cross-functional nature of the work, the focus on uncovering real user needs, and the shift from promoting a solution to actually being part of building one. “In digital marketing, you’re promoting a solution — you’re not necessarily part of the solution,” she said. “I wanted to be part of finding problems and defining solutions.”
Getting the First Role: More Grunt Than Glory
If there’s a theme running through the “how did you actually land it?” conversation, it’s this: persistence, networking, and a willingness to play a long game.
Jane took a strategic approach from the start. She joined a government-funded Digital Jobs Program that offered career coaching, tuition, and an internship. But the real breakthrough came from showing up — genuinely and consistently. She built her network, had coffee chats, and eventually posted on LinkedIn with a photo of her and her dog. “Everyone loves a good dog,” she said, “but through that I was introduced to 20 or 30 different people.” One of those connections was a VP of Product who, a month later, reached out about an open role. It had been listed as Senior Product Manager — too senior — but was reclassified as an Associate PM role to make it work. “About 90% of the jobs I’ve had have been in the hidden job market,” Jane said. “So keep being curious.”
Carrie’s path was more grinding. She wrote approximately 65 applications. She did a product management course. She had coffee chats. “I don’t necessarily think the course really helped, but it was interesting,” she said. “I didn’t get the impression that whoever interviewed me cared about the fact that I got this course.” Towards the end, hope was fading — she was about to walk into a digital marketing interview when a contract PM role came through. “Don’t give up. Keep going. You’ll eventually get to land the role.”
Both emphasised the value of translating previous experience deliberately. Carrie highlighted product communications as something her marketing background gave her real fluency in — something she noted that many PMs deprioritise. “Product comms is, quite surprisingly, not something that’s well done in a lot of products. It’s like the last thing product managers really get to.” Jane pointed to the transferable power of collaboration, stakeholder management, and navigating organisational complexity. Her advice: ask people in product roles what they actually look for when hiring. “It’s a pretty good chance you’ve probably got some of those skills already.”
The Biggest Misconceptions
This was where the panel got most candid.
Hugh arrived thinking product management meant making decisions — that he’d finally get to be the one calling the shots, in contrast to his years as a designer being handed requirements. The reality was a recalibration. “Thinking that I was the person slamming my fist and saying ‘this is what we’re going to do’ was wildly incorrect,” he said. “It is a discussion in which you are one person.” Product, he found, is far more democratic than autocratic — and the further he got from a founder-led context, the more that became apparent.
Carrie had absorbed the familiar line that “the PM is the CEO of the product.” She now considers that one of the more damaging myths in the discipline. “There’s some stuff that’s really fun, and there’s also some really shit stuff too,” she said. The grunt work is real. Time is always short. “You’ve never going to have enough time to put stuff in the backlog” — something her people manager delivered not as bad news, but as a matter-of-fact welcome to the job.
Jane had done the reading, taken the courses, loaded up on frameworks. She expected that preparation to translate into clear, applicable answers. It didn’t, quite. “There are frameworks out there — some of them are great — but you won’t likely be in a situation where you can apply something that’s written in a book to a situation and have that work.” Product management can feel circular, iterative, and messy in ways that no framework fully anticipates. Learning something new often means going back to the drawing board. “I just didn’t expect that as much to be the case.”
Advice for the First 90 Days
The closing question — what would you do differently in your first 90 days? — produced some of the sharpest advice of the night.
Carrie would start asking hard questions earlier. “Not easy questions, but maybe some challenging questions — or you have to ask the same question over and over because you don’t get the answer and you might need to reframe it.” Sitting with that discomfort is part of the job, and the sooner you practice it, the better. She’d also lean harder on the cross-functional team. “You don’t need to figure it all out on your own. If you’re working with engineers or designers who have worked with product managers before — ask them what worked and what didn’t.”
Jane would spend the onboarding period talking to customers as aggressively as possible. “Spend that time getting to know your customers.” She’d also invest deliberately in meeting people across the organisation — not just to be sociable, but to understand what’s keeping people up at night and where the real points of friction are. “Getting genuinely to know people across the business, but also what are some of the things that are really important to them and their challenges.”
Hugh offered the contrarian take: get outside the organisation entirely. The risk of spending your onboarding learning “how to do product the X-company way” is that you absorb one approach as if it were the only approach. “There are so many different ways to do product,” he said. “Experience how other people approach it, and see very different ways of solving those problems.” Events like Product Camp, he suggested (with a self-aware shameless plug), are one way to do exactly that.
The Thread Running Through All of It
What ties these three stories together isn’t a common background or a tidy career arc — it’s a pattern of deliberate curiosity. Each of them noticed something that wasn’t working, started asking questions, found people willing to talk, and kept going longer than felt comfortable.
Product management, it turns out, selects for exactly that. Not the person with the best instinct for decisions, or the one who’s read the most books, or the one who can apply the most frameworks. The person who asks the awkward question, reframes it when the first answer doesn’t land, and builds a picture from the ground up.
That, at least, is something you can start practising before you even have the job title.
In today’s competitive world, companies are always looking for a way to stand out against their competitors. In the past they may have achieved this through features or advertising. More recently organisations have started to differentiate themselves by rethinking the whole customer journey and delivering an amazing experience around all aspects of the product.
We call this “Product-led.” This doesn’t mean that it is “product manager led,” it means that the whole organisation and product is oriented around customer and business success.
Amy Johnson from Propel Ventures led us through 5 steps to bring Product-led thinking into your organisation
What is Product-led?
Product-Led is “a relentless focus on customer value to create products that sustainably drive growth”
When we dig into this a bit more, Product-led is about focus on the value the product creates for your customers and your business. For example this could be in the product pricing, Go To Market activities, or design. This involves having a clear vision and an empowered team to deliver against the vision
Why does Product-led matter?
Product-led is more beneficial to a business as it has a long term growth in mind, as well as minimising waste. Conversely, Sales-led often means only focussing on the next sale, so is not sustainable in the long term. Technology-led means building cool products based on the enabling technology, but risks creating products that don’t solve any problems.
This article will drill into the the 5 core tasks necessary to move to Product-led
Product Vision
Product Strategy
Shared Success Measures
Organise around value
Outcome based roadmaps
Let’s dive into each one
Product Vision
A good vision provides clarity on the future, so you know where you are going. This clarity is important because going fast in the wrong direction won’t get you to success.
But you won’t be able to create one by yourself. Vision creation should take in diverse perspectives and different voices to make sure it is clear. Use these voices to focus on the change you want the product to make in the world. You need to find a vision that will inspire the team.
You’ll know when you have a good vision when it is easily internalised by the whole team.
Product Strategy
Product strategy is about mapping out the path to get the product vision. This requires understanding the strategic intent, the challenges and the business goals. Use this knowledge to then clearly articulate the goals, which are prioritised based on strategic intent.
There is a risk in skipping this thinking if you join an organisation. You may inherit everything that is already going on. While it is possible to artificially create a bottom-up strategy by reviewing the backlog and package it into themes, there is a risk that it does not achieve business goals. It is important to make sure your strategy is aligned with the product vision above.
Focus is a key part of delivering against the strategy and vision, so clearly articulate the goals and ensure all activities are targeted towards business goals
Shared Success Measures
Having clear success metrics that are shared helps the organisation achieve alignment, by describing what “good looks like.” It is important that these are legitimate measures of success based on customer value, rather than metrics that might be easy to measure but won’t help you know more if you are on track – known as “vanity metrics.”
Ideally these success measure should be outcomes, not outputs. Outcomes are what the business needs to achieve, whereas an output is a delivery that contribute towards achieving that outcome. For example, the customer cares about how you have saved their time and money, rather than whether you released a feature or not.
To create these success measures, you’ll need to know what is valuable to the customer, as well as a way to measure it. Finding a way to know what good looks like in the product can ensure you are tracking towards a common idea of success.
Organise around value
There is a risk in organisational design that you create teams around what the company values rather than what the customer values. This is known as Conway’s Law – where complicated products end up looking like the organisational structure.
To ensure the customer gets the most value out of the product, the company should be organised around the customer’s perception of value with the product. Create a journey map to understand the customer experience, pain points, opportunities and make sure the end-to-end experience works. From there you can define the problem to solve and the metrics of success. Once you have these you can experiment and iterate.
Outcome based roadmaps
Once you know where you are going, how you are going to get there, metrics to measure customer outcomes, and what the customer values, then you need to ensure that delivery stays on target.
An ‘outcome-based roadmap’ takes what is known about how the customer or business measures success, and gives context to every item on the roadmap. It articulate goals and what you are trying to achieve. It also reiterates the product strategy and makes sure that unnecessary items don’t appear on the roadmap.
This makes the roadmap a communication tool, not a project plan. One way to enforce this thinking is to use the now : next : later format. This is a more realistic view given that development is not always predictable, and it allows flexibility to change based on customer feedback
Summary
Product-led is the way to focus the organisation on success; through identifying customer value and sustainable business growth.
There are 5 key areas that need to be consider to successfully make the transition:
Product Vision – A phrase that describes the future to align and inspire the organisation
Product Strategy – This maps out the focused path towards the vision
Shared Success Measures – Aligns the organisation and tell you if the strategy is working
Organise around Value – Ensure that you are aligned to clear customer value
Outcome Based Roadmap – Ensure that delivery stays on target
About our speaker
Amy is a product leader, passionate about empowering teams and fostering inclusion. Multi industry experience, now leading the product team at Propel, who partner with you to accelerate your product development and achieve product market fit faster.
Thank you
Thanks to our wonderful friends at Everest Engineering who hosted the event.
And here’s a bit of behind the scenes setup action via Bryce’s tweet
Caitlin Blackwell is the acting Head of Product for the candidate experience at SEEK. Caitlin joined us last Thursday to talk about continuous discovery and how SEEK is using this framework.
Caitlin talked to how you can generalise the product manager role into 2 areas – deciding what to build and then building it. Teresa Torres talks to how we have gotten really good at shipping quickly via Agile, Lean Startup and other frameworks. We haven’t had the same emphasis on deciding what to build – ie continuous discovery.
We risk wasted effort when we rush to building and don’t do the work to understand what is needed. We can build an MVP quickly but you might have to wait a while until you have a good enough sample size or feedback to keep moving forward or realise you don’t have the right solution.
Caitlin believes discovery is all about being able to make better decisions through the product process. There’s several reasons we make bad decisions (aka the villains) including lack of clarity on the problem, being overconfident, etc.
A part of Teresa Torres’ framework they use is opportunity maps. This visual mapping lets you clearly state the outcome you want (linked back to your OKRs of course!), show the customer needs and show several solutions that may help you reach the goal.
Speaking to customers is key. Caitlin said their teams (ux & product combined) do 5 customer interviews every fortnight with a standup at end of day to share insights with the rest of the team. It’s important to talk to customers to learn about them, not only test out ideas.
The map helps to visualise the situation though you still have work to do in order to decide which customer opportunity and solution to move forward with. After sizing the opportunity to decide which to explore, you should ideate & validate assumptions through experiments.
Caitlin walked through one example where the OKR was to increase the SAT score of a particular customer segment. She shared some of the tools and ways SEEK walks through continuous discovery. (See the slides at the end this article)
Once you’ve decided which opportunity to go after, it’s time to ideate & validate. There are different tools you can use to experiment and test your ideas (slide 21 has a list).
A few tips:
Spend 5 minutes a day to brainstorm. Frequently spending a short time is less cognitively draining than an hour brainstorm!
Do what you can to learn quickly in order to move forward. Talking with 2 customers is better than no customers. You can still learn something from those 2 (sample size is important but you can learn and be smart about what you’re hearing from small numbers)
Map your assumptions! Decide how you validate/disprove each of them.
During the talk, Caitlin gave us a few examples of how using continuous discovery can help create better products.
First up a product fail. When launching a new product which employers did not have access to, they came up with an ‘access code’ solution process to assist. The team ran an experiment to test the process but didn’t test their assumptions enough before launching – particularly really questioning the desirability and usability of a long process. The sales team’s feedback from employers was it is difficult to change behaviour without showing the value of doing so.
A win… SEEK wanted to introduce the ability to search for jobs by commuting distance. They listed their assumptions, what data they needed to assess risk and how they’d get that quickly. Testing made them realise it’s not just distance in km that’s relevant to job seekers as 10k on a tram vs a highway trip is very different time wise. Experimenting allowed them to dig deeper into understanding the candidate need.
How can you get started with continuous discovery?
Talk to users frequently. Ask them how they use your product.
Decide what metric you want to shift. This could be your OKR.
When ideating, go broad. Go for quantity. You can narrow later.
Do some sort of assumption mapping before you start building. Even if it’s listing out assumptions without a framework.
To Learn More
Caitlin recommends the following:
An introduction to Modern Product Discovery & more resources – Teresa Torres
Most teams have gotten really good at delivering quickly, and measuring our results. However sometimes we can get a bit addicted to shipping fast rather than right, listen to our assumptions too much, and relying on A/B testing to validate if we’ve delivered value.
Hear about the struggle and joy of a journey of continuous discovery, and some examples of validating ideas before building anything.
Our presenter: Caitlin Blackwell is Acting Head of Product – Candidate Experience at SEEK. She’s previously been in Product Manager roles across many parts of SEEK over the past 7 years, and is currently focused on driving the candidate vision for all of SEEK’s jobseeking products.
Continuous Discovery
Teresa Torres defines Continuous Discovery as weekly touch points with customers, by the team building the product, where they conduct small research activities, in pursuit of a desired product outcome.
That sounds easy but it is a lot of work to adopt if not already a habit. Some of the mindsets needed to do this well are:
A collaborative mindset: Do you have the right people involved in each decision?
A continuous mindset: Are you continuously discovering opportunities and solutions?
An experimental mindset: Are you prepared to be wrong?
Teresa Torres has another great video explaining the value of continuous discovery and where it fits in with the many other methods we may be using already. Join us this month to hear more about what it takes to implement and the benefits to be gained for you and your team. RSVP now
Thanks to our wonderful hosts RMIT Online.
Launching Australia’s first University program in Product Management on the 1st of June to help fulfil the emerging skills gap in product management! It’s a Graduate Certificate – Masters level, 4 subjects, and can be completed in 6-12 months.
Andrew Knibbe, Head of Product – Direct Hirer at Seek – has over 10 years of product management experience – cutting his product teeth in the early days alongside the ThoughtWorks team at Sensis followed by stints at Carsales and Flippa before moving to SEEK where he has had Head of Product roles across both the Consumer and Business side of the employment marketplace. He remains excited about what OKRs can mean for product teams (and customers!).
Wayne Allan, Technical Product Manager, REA – A muso turned software engineer turned product manager, I love creating things people love! Currently solving problems at realestate.com.au
Brad Dunn, Co-founder and Product Director at OHNO. Before that, he was the executive for Product & Customer Experience at Geo. For 7 years, Brad was the CEO of Nazori, a mobile product development business, where they worked with clients in 12 countries around the world including Samsung, Airbnb and Aesop.
The OKR Process
Andrew let us know that every team at Seek manages their OKRs a little bit differently & they’re currently in their 4th or 5th quarter of doing OKRs.
Andrew described a very team based approach (which is what Wayne also talked to). About 6 weeks before the end of the quarter, the teams receive some context on where the business is going & what they’re seeing in the market. About 2 weeks before the end of the quarter, the team incorporates their own research & knowledge to create draft OKRs for the next quarter. Drafts are reviewed to ensure they are aligned across the portfolio.
Setting OKRs is only part of the process – you need to understand how they went & learn from them. At Seek, there’s check-ins during the quarter (even just emails) and at the end of the quarter, teams present how they went for each OKR, what that means for the roadmap & strategy going forward and what the next set of OKRs are. REA has a mid-quarter update to ensure you’re on the right path or if there’s roadblocks that need to be cleared.
Wayne reminded us that part of the process is needing to educate your team about OKRs. Some people might think they are tied to performance or compensation so you need explain how the OKRs work. As the acceptance of OKRs builds across the business, you need to keep educating different groups.
And Brad noted they do not follow the usual quarterly OKR cycle! They work to a 6 week plan because that’s what works for them.
There was clear agreement between our speakers that OKRs can create alignment between teams & stakeholders. They set expectations on what to do, not how to do it. They force prioritisation early on. They help people understand why you did X and not Y. Brad believes they are great for helping people believe in something & getting people to rally behind something.
Wayne believes they help speed up decision making as the product manager doesn’t have to answer everything. People on the team know where they are headed which drives performance within the team.
Based on what our speakers said, it seems they can also help raise issues. Use the OKRs to help show when a deliverable (that’s been delivered) needs some help. If a senior stakeholder says to build X, use the OKRs to manage if that’s the right thing to build.
Brad uses a combination of focusing on outcomes and PIRATE metrics to drive OKR setting.
Tips from REA's Wayne Allan. Answer questions like : is this tied to my bonus? Get your #okrs wrong quickly. Use them as an opportunity to learn. Don't have 26 KRs. #prodanon
Creating your OKRs can be tough. You need to provide enough context for the teams to make good OKRs. Don’t have too many – recognise that even 3 objectives can be too many and 26 KRs is definitely too many. Changing the objectives every quarter can be too much context switching with not enough time to make real progress. They should not be a task list.
Wayne said they realised during planning that they had 3 objectives that were exactly the same thing but had been written in 3 different ways. The team used 3 1-hr sessions to get all their ideas on post-its, all the concrete ideas out and used that to help think at a higher level (& get the entire team onboard).
Make your OKRs part of everyday life can be a struggle. What do you do if half way through the quarter you’ve smashed it? or realised it’s not something you should do.
Measuring your OKRs needs to happen. Wayne advised us NOT to have a set & forget attitude. He suggested setting up your measurement plans in the 1st week. AND not to use surveys to measure everything as there will be survey fatigue from customers & internal folks.
Don’t focus totally on the OKR. Brad finds it fascinating that people really focus on the OKR.. what’s a good one, what’s a bad one. He sets them and then focuses on the outcome.
Brad talked about the concept of ‘mental contrasting’ which consists of 4 items and the first 2 are tied to what an OKR is.
Wish – the inspiring thing you’re going for ie your objective
Outcome – your KR
Obstacle
Plan
With mental contrasting, you should take a little time to think about the obstacle. Just thinking about it, helps you act.
FYI, this is also called ‘WOOP‘ (easier to remember than mental contrasting!)
Questions
What’s the worse KR you’ve seen? Andrew: “TBC” Brad: putting in an OKR we knew we couldn’t meet – or vanity things.
How long does it take to pull together OKRs? Brad says it’s about 2 days (every 6 weeks). Andrew says it’s much less now that they have done this several times and they don’t change their objectives every time. Wayne has time boxed theirs to 3 hrs.
Wayne & Andrew also talked to the difference between old & new products. New products might need longer to work out the OKRs as opposed to tweaking existing products.
https://www.instagram.com/p/BxzKH8FHVFC/
Thank you!
A massive thank you to Andrew, Wayne & Brad, our wonderful speakers for the evening! To our fantastic volunteers for the evening: Gwen, Steve C, Steve B, Rob, Neha, Nigel & Marija. To all attendees!!! And to Medibank for hosting!!!!
I first heard of Wardley Mapping about 2 months ago and then the name started popping up in a few places which got us investigating it as a potential topic. Coming at it from zero knowledge, it seemed like the sort of thing product folks should know more about as it concerned both strategy & decision making.
Kim Ballestrin, Principal Consultant at elabor8, talked us through the basics and got us creating a map by thinking through the user needs capturing & protecting their personal data when using social media.
The What of Wardley Maps
A Wardley Map is a representation of the landscape & environment a company operates in. Its creator, Simon Wardley, believes a leader should have a map of the terrain to help guide their strategy.
The map consists of the activities the user needs to accomplish their goal charted across lifecycle, supply & demand.
You can use this framework in several ways, such as:
To think about your ongoing product development – from USP to commodities
A way of looking at the market or competitor landscape
Process and value chains from understanding where you have no standard process to defining a highly standardised process
https://www.instagram.com/p/Bvi038tHl7z/
The Whys of Wardley Maps
The map is a great way to create discussion. Once created, scan your map from top to bottom and left to right to determine if there are specific decisions that need to be made. Look for assumptions you’re making on the map or within your existing thought process.
Bonus – The How of Wardley Maps!
There’s a few principles to keep in mind when creating a Wardley Map:
The user need is your starting point
Keep it simple and on a small scale – don’t try to map EVERYTHING!
Your map will be imperfect – and that is completely ok!
How to create a Wardley Map
Define your user’s needs.
What are the activities the user takes in order for those needs to be met?
Drill down into functions & features based on the visibility of the features to the end user.
Chart your functions & features from left to right along the evolutionary axes. The axes go from bespoke (genesis) on the left to generic (commodity) on the right.
Sketch in the linkages between the features & functions. This gives a good landscape of where you are right now.
Mapping out these connections and perhaps seeing where you may be too dominant in your commodity space & thus are at risk of disruption. Or understand that you’re too heavy in custom services, which bring high cost to serve & thus its time to consider streamlining the business by moving those to a product stage. These are some examples of ways a Wardley map helps you see the landscape and make better strategic decisions on what to do next as an organisation.
There are lots of different ways to use maps.. Your competitors, processes, etc. The point of a map is to have a conversation #prodanonhttps://t.co/ITkI8RMMhK
ProdAnon also had a bit of a surprise! The man himself, Simon Wardley, creator of this framework just happened to be in Melbourne Thursday evening and attended the session. Thank you Kim for inviting him!
Simon was kind enough to take some questions from the audience & talk through how he came up with his framework all those years ago.
Wardley Mapping – @swardley says Maps are by nature, imperfect; change the location of something and it’s meaning changes; maps just describe the landscape, nothing more. They are a tool for decision making. #prodanon#ProdMgmt
We opened 2019 talking about roadmaps – a topic we had been asked in responses to our annual feedback to spend some more time on. We invited our speakers to share their different perspectives on roadmaps… and we heard come common themes to help understand how to keep a roadmap from controlling your life, and how to turn it into a fabulous communication and vision guide for inspiring your teams, plus some sage advice relevant to each organisation who took the stage that evening.
Below are some highlights from each talk plus the slides from each speaker – feel free to reach out to any of them if you would like to chat more. Plus we have added some references to other resources to read and explore at the end of this post.
David Bignall / Seek
David had much to share – ultimately not a fan but he did share some tips on how to help make them work for you rather than be a slave to them!
Roadmaps are a thing, every company has them so you will
encounter them. David used this deck at Seek over a year ago to his team and
people so proof they are a real thing, but after having the discussion has
helped wean the team/group he is on off them.
For David when sharing what he thinks a roadmap is showed a
map – because it is a journey to an unknown place.
“A document to capture and quickly convey a team’s big-picture goals, specific objectives and their imagined path to success” – Dave
“A company roadmap is a document to capture and quickly convey its big-picture plans and objectives” – prodplan.com
“The first purpose is because the management of a company wants to make sure that the teams are working on the highest value items first, relevant to the company strategy.
The second purpose is because businesses may have date-based commitments. The roadmap is where they see and track those commitments.” Marty Cagan, SVPG
They can be useful – but they can also be a big waste of
time – common issues:
Intended goals/purpose are not stated or are not clear
Often far to specific
You can’t have that much foresight 9 months away
They do not account for “time to value”. Iteration is almost always needed to realise the full value of a new product/feature – (David bravely shared an own example of a very bad roadmap!)
Put item on there and them immediately moving on to the next thing
Ignoring the process of iteration or things going wrong
Detail on roadmap can lead team to auto-pilot. They build what they put down on paper often months in advance
Team goes into auto-pilot. As if this is their job, rather than thinking of most value to be delivered for the customer
Distributed copies are out of date
Keeping stakeholders up to date can drain your time. You don’t want to feel like you work for the roadmap, and it is just sucking your time from doing real work.
“Many untested hypotheses, based on assumptions, plotted in an uncertain future, bearing no resemblance to reality” Jared Spool
Dave’s top tips for roadmaps
Show where you want to go
Choose granularity relative to the timeframe and
audience
Avoid specificity (Show the problem or JTBD or
objectives as descriptors of intent rather than the solution)
Whitney opened with sharing a story about her experiences of
not liking roadmaps because she has never seen a roadmap, become reality. She
first got to know REA when working at a company in the US, and became a slave
to the roadmap as they committed to work they would deliver to this customer.
Then, she joined REA and was so excited about agile and thought, YES! I’ll get
away from roadmaps! But she was fooling herself – see the beautiful roadmap on
the wall at REA (pictured in slides). However, she soon found that REA was
using roadmaps and needed to due to the big size of the organisation and the
need to coordinate a lot across so many teams, groups etc.
However, in Whitney’s attempt to accept roadmaps and make peace with the need for them she started asking “Why do people ask for roadmaps?”.
Some of the things she learnt don’t work when using them:
Don’t work as a promise
Too much detail – just a list of lower level
features
Lose focus on what the customer needs.
REA owns a lot of companies and even just within
Realestate.com a dozen delivery teams.
“Satisfaction is a confirmation or dis-confirmation of expectations.”
Example of people waiting for train for 15 minutes but
dissatisfied, and others warned that train will come at 5:30 and apologies for
the delay, did not rate their travel experience as dissatisfying as compared to
the first group as their expectations were met/managed.
With that in mind let’s try to think what this artefact does
to satisfy our leaders.
So what are they currently doing with Whitney’s team – they
use a 90 day view – showing a commitment up to 90 days. No promises beyond that
– great for delivery teams. Not great for stakeholders.
For stakeholders they use a Discovery backlog (second 90 days) and an Opportunity backlog (all the rest – no priority) – people now satisfied that their idea is on there – somewhere. Others groups understand that stuff that comes out of Discovery will most likely make it to the committed version and the conversation is being moved to a different stage of team flow.
I encourage you to seek to understand with genuine curiosity, the needs of anyone who has a problem and thinks that a roadmap is the solution. Whitney
Keith Swann / Origin Engery
Keith brought to us a more positive upside to the roadmap
discussion
His beliefs are that they help with:
Alignment – up or down
Influence – rarely based on dollars
Leadership – how do we inspire people and rally
them to our cause
Alignment
Everyone will scrutinize it to their own
beliefs, so do it carefully – target on your back
Strategic – Financial, PMOs, GMs, etc. etc.
interpret the stuff and then try to manage up and down.
Cultural – make sure it talks to your audience
Influence Record – Successful record of moving
things along. Better record = less scrutiny
A road map is a Story telling device and the aspects Keith uses are MUM, Problems, Position, Opportunity, Value. How do you tell the story, “up or down” the organisation. Think of the “Cone of influence” – below people can make lots of small decision but not big decisions. As you move up you get spun out if you aren’t managing those stakeholders.
Eisenhower: Plans are useless, but planning is
indispensable
Every day the plan can change – the second your
plan is finished it is out of date.
Roadmap = Vision.
Takeaways
Don’t put in too much detail
Think of your audience – Working Tested Feature
– WTF
Don’t muddle the Project Mindset – Delivery
Planning – Bookending with a roadmap
Don’t become vague in your horizon 2 and 3 –
don’t over promise
Make it easily editable and manageable
Post Its on the wall and photos
Over invested time of effort – working with
visual designers. 5 days work and 6/7000$ and printed in colour. Thus, you deliver
to the roadmap even though you don’t want it anymore because too much effort
went into the artefact.
Don’t clearly show values
Don’t focus on the feature – focus on the
problem or opportunity.
Roadmaps may very well be a necessary evil, especially in a big organisation when you have many teams and people to motivate, inspire and align. However, our speakers have shared some great tips to help keep you from being a slave to them as well. For some more references and reading on steering clear of them and/or leaning into making them work for you check out some of the links below:
Marty Cagan is not a fan and in these post he links to OKR’s which came up in both the speaker presentations and the questions afterwards.
And last but not least for a more practical tuition on taking back control of your roadmap you could check out Bruce McCarthy’s seminar on UIE
A few key slides from tonight's #prodanon Meetup in Melbourne on roadmaps: tearing down assumption-based, feature-filled, date-driven #productroadmaps, and sharing better ways to communicate the outcomes we're focusing on delivering to help achieve a bigger, longer-term vision pic.twitter.com/0qoyYxlNft
