There’s a moment in almost every product career where you build something thoughtful, ship it carefully, and then watch people completely ignore it. Not because they don’t care – but because changing behaviour is genuinely, stubbornly hard.
That’s the problem Alex Waddell, behavioural and implementation science practitioner, researcher, and lecturer, has spent her career trying to solve. At our recent Product Anonymous session, she gave us a fast, hands-on tour of behavioural science and implementation science – and how product people can actually use both.
First: What even are these sciences?
Behavioural science is an interdisciplinary field drawing on cognitive science, economics, psychology, sociology, and neuroscience to study human behaviour and design strategies to change it.
Implementation science – which was born out of healthcare, where it takes an average of 17 years for research to reach the patient bedside – asks a different but related question: how do you get something that works into an organisation or system with speed, fidelity, and quality?
One is more micro. The other is meso and macro. But both ultimately boil down to the same question:
Alex said this was the one thing she wanted us to take away. It’s deceptively simple – and it cuts through a lot of the vagueness that plagues change initiatives.
Step one: Get brutally specific about the behaviour
Before you can change a behaviour, you have to specify it. And this is harder than it sounds.
Alex asked the room: what behaviour am I doing right now? In about thirty seconds, the audience shouted out ten different answers – presenting, talking, staring, moving around the room. They were all correct. And that’s exactly the problem. If you can’t pin down the specific behaviour you’re targeting, you can’t measure it, and you can’t change it.
To get specific, Alex introduced the AACTT framework – a tool for mapping behaviour across five dimensions:
Action – what can be observed and measured? If you can’t observe it, you can’t change it.
Actor – who specifically is doing (or not doing) this behaviour?
Context – the physical location, the social setting, and critically, the emotional context.
Target – who is the behaviour being performed for or with?
Time – when is it happening?
The emotional context piece generated a lot of discussion in the room. Participants reflected that we tend to design for the rational user, in a neutral state. Real behaviour happens in emotional contexts – rushed, distracted, anxious, under social pressure – and those contexts matter enormously.
Step two: Stop going straight to solutions
Once a behaviour is specified, the instinct is to jump to solutions. Alex made the room do exactly this – using a photo of a woman examining apples in a supermarket, she asked how we’d increase apple sales to her.
The ideas came fast: discount signs, taste testers, better labelling, smaller bags for easier carrying, large-font labels, recipe cards. All reasonable. All based on assumptions.
Then she asked: what assumptions are we making about this woman?
The list was long. That she has grandkids. That she has poor eyesight. That she can afford apples. That the apple is even for her. That she buys apples at all.
“We need to be really, really careful about assumptions. People are not like us. They don’t have your lived experience, they’re not from where you’re from, they’re dealing with other things.”
The exercise was a pointed reminder that we design for ourselves more than we realise – and that good research with and for people is non-negotiable before you reach for solutions.
The frameworks: COM-B and EAST
Alex introduced two frameworks worth keeping handy.
COM-B
Synthesised from 33 theories, models and frameworks by Susan Michie and colleagues at UCL, COM-B says that for any behaviour to happen, a person needs three things:
Capability – psychological and physical ability to perform the action (knowledge, skills, stamina)
Opportunity – external factors that make the behaviour possible (time, resources, location, cultural norms)
Motivation – internal drivers, both reflective (conscious plans and beliefs) and automatic (impulses and habits)
One insight that landed particularly well: motivation includes beliefs about other people’s capabilities, not just your own. Alex drew on her PhD research into shared clinical decision-making – where some clinicians assumed certain patients didn’t want to be involved in decisions about their care, and so never offered it. A belief about someone else’s capability, cutting off behaviour before it started.
EAST
A more action-oriented framework from the UK’s Behavioural Insights Team, EAST gives you four levers:
Easy – reduce friction, simplify messages, use defaults
Attractive – make it stand out, use images, personalise, consider rewards
Social – show what others do, use networks, make commitments visible
Timely – prompt at the right moment, consider habits, plan for barriers
Alex walked through a famous cautionary example: a sign that read “Littering in our local area has increased” – intended to encourage people not to litter, but framed as a social norm that actually increased littering. When you tell people that something bad is happening a lot, you inadvertently signal that it’s normal.
The lesson: always test before you roll out. Behavioural interventions can backfire.
There are 93 behaviour change techniques
One of the most eye-opening moments of the evening was learning there are 93 identified behaviour change techniques – and that the instinct most organisations reach for first (training, education, an online module) is just one of them.
“People most often say, ‘let’s just do some training and they’ll [the people whose behaviour you are trying to change] will do it.’ They probably won’t. Or they might, and probably not everyone.”
The richness of options is the point. If your current approach isn’t working, there are dozens of other levers to try – and a growing body of evidence about when each one works.
The key takeaway
At the end of the session, Alex asked the room to spot how she’d used behavioural science in the workshop itself. The answers came quickly: prizes for participation (incentives), the active listening exercise at the start (priming for engagement), the Slido polls (social proof, visibility), the hands-on activities (behavioural practice) rather than passive listening.
It was a neat way to close – and a good reminder that these frameworks aren’t abstract. They’re design tools. Every product interaction, every onboarding flow, every survey you send is a behaviour change attempt. The question is whether you’re doing it intentionally or not.
Want to go deeper? Alex has compiled aresource guidewith links to the frameworks mentioned – including the behaviour change technique taxonomy, the Theoretical Domains Framework, and the EAST playbook. Grab it, then find Alex at coformed.com.au to see how she helps teams turn good ideas into lasting change – and get in touch. Connect with her on LinkedIn too.
Thanks to our hosts
Thanks Zendesk for being our wonderful host for the evening!
Editor note: citations for works quoted or referenced here are included as direct links to the source material.
Since 2019 Amir and David have been catching up for what they term ‘shit sandwiches’, exchanging professional and personal trials and successes, sharing sympathy and occasional advice. Should I leave my job; how do I handle a difficult report; how do I get buy in; and do you know a good osteo you could recommend, my back is killing me.
They’ve have turned our catch up sessions into a live, high stakes gameshow for the product community’s amusement.
They will be borrowing from the ‘who wants to be a millionaire format’ and we will share stories that will hopefully inspire people to step up and lead (when required) in this messy and uncertain world we find ourselves in.
Get ready to have some fun and hopefully learn a thing or two.
Our Speakers: Amir Ansari: With over 25 years’ of experience in the field of design and design leadership, Amir has worked across the private and public sectors, in-house and agency, managing design practitioners and leaders to build long-lasting and impactful products and services. Amir is passionate about democratising the craft of design and sharing my learnings – doing it with a smile and a hug.
David Bacon: After graduating from Monash with a Bachelor of Science, David worked as a penguin keeper in England which somehow lead to a career spanning marketing, behaviour change, innovation and human-centred design. David has experience delivering digital products and services in financial services, healthcare, retail, government. He has the goal of weaving humanity into technology. He still dreams about penguins.
Our hosts: ROLLER is the cloud-based venue management platform for modern attractions, purpose-built to remove friction from the guest experience at every touchpoint. Their all-in-one platform simplifies business processes, improves efficiency, and maximises revenue — spanning Online Checkout & Ticketing, Point-of-Sale, Integrated Payments, Memberships, Gift Cards, Waivers, Self-Serve Kiosks, Cashless Wallets, Guest Surveys, and more. Behind the product is a team that operates with high ownership and genuine collaboration across Engineering, Product, and Design. At ROLLER, builders are expected to think commercially, move with urgency, and care about outcomes — not just output. To learn more, visit roller.software.
The following is a recap of a panel discussion on AI in product, engineering, and operations. Panelists were Daragh Kan (Head of Product, Cuttable and hospitality entrepreneur), Dave Slutskin (Cadence), and MelissaCupples (Head of Intelligent Products and Automation, Humanly Agile). The session was facilitated by LizBlink, Co-founder of Product Anonymous.
Over a year ago, a small Slack channel was set up with a simple purpose: help each other figure out how to use agents. It looked really hard then. It still is – but the pace of change has been remarkable, and the conversation has moved with it.
This panel brought together product and engineering leaders who are living in that change every day: building AI products, running their teams with AI, and trying to work out what the role of a product person actually looks like in 2026. There were no tidy answers – the panelists were the first to say so – but there was a lot of hard-won experience, a few genuinely useful frameworks, and one story about chicken salt that the room won’t forget.
If you’re a product person trying to stay on the right side of this shift, there’s something here for you.
Who’s in the Room
Daragh runs product at Cuttable, an AI-powered ad tech startup working with e-commerce and service brands – taking brand assets, augmenting them, and pushing them out as ads across Meta, TikTok, and other platforms. Outside of that, he’s been running bars and restaurants for about 20 years, which gives him a unique lens on bringing AI into non-technical, sometimes smartphone-free environments.
Dave has spent 25 years in tech – writing code, managing products, and leading developers. His current company, Cadence, looks in minute detail at how developers use AI coding agents, helping individuals and their managers understand what good looks like in a world where that’s still being figured out. “I suspect if we come up with any answers tonight, I think we’re probably doing it wrong – because there’s no right way to do any of this stuff at the moment.”
Melissa leads engineering and product at Humanly Agile, an AI consulting and product-build company. Her team builds AI products for clients – internal and customer-facing – while also using agents to run their own operations. “Pretty much everything we do is powered by agents that allows us to do 50 times the work we could do with our very small and constrained teams.”
The Pitfalls
Liz: You’ve all stumbled along the way. What were some of those moments?
Melissa: I come from an engineering background, so I was using AI tools early – back when everything was being introduced. That was my first experience of how things could go wrong. Using agents and putting system tools in that environment, you quickly see how things spiral out of control. Things are quite good in a greenfield environment, but as soon as you hit any complexity at all, it can get very unwieldy. A lot of what we’ve learned is about how you control your environment, your context, your structure. There’s quite a lot of thinking and scaffolding that needs to be in place for effective use of AI in any context.
Dave: There’s a mental model thing we’re all developing, and I think it’s weird. Sometimes it feels like you’re working with a co-worker, and sometimes it feels like you’re working with a tool. With a co-worker, when something’s misaligned, you need to work it out – because it’ll come up again. With a tool, you can just kill it and start a new one. What I see with people who are new to this – and what I sometimes still catch myself doing – is spending a bunch of time arguing with the agent for no reason. It doesn’t get you anywhere. There’s no value in those tokens you spent, or in the tokens it spent apologising and justifying. I think one of the pitfalls is this uncanny valley – it sort of feels like a co-worker, but it’s not.
Daragh: There’s also this single-player mode problem. Before AI, if I needed help from Dave, there was a visible record – a Slack message, a conversation. Now a lot of that’s just happening in chat windows. On the flip side, I can get immediate help without waiting a week. But I’m noticing there are fewer questions being thrown around. People are quieter. And it’s also really easy to start with very little planning, which can be good – throw some ideas out and see what emerges – but it can also mean you’re three minutes from deploying something you haven’t properly thought through.
The Joy
Liz: What was your “oh, f**k yes” moment?
Melissa: For me, it was truly solving a customer problem that could not have been solved without generative AI. A paradigm shift of: wow, this wasn’t even possible before. That’s why I get up in the morning – we can actually look at all of these problems that until now couldn’t be solved.
Dave: For me, it’s doing things I wouldn’t have got around to. I can just say: go look at all our competitors, understand what they did last month, find any new ones that have appeared, map the landscape. That’s foundational product work I used to revisit every six to twelve months. Now it just happens. I still find it critical to build product vision and strategy in my own head – I’m not outsourcing that – but having the data pulled together and accessible? That’s pretty fantastic.
Daragh: I fired our agency managing restaurant ads and inherited a Google Ads account I hadn’t touched in five or six years. I opened it up with Claude, said “what is going on here,” and it kept asking for more access – Analytics, search terms, Shopify data, organic rankings. I kept saying yes. And then it came back with an idea for an ad that I would never have thought of, because it had pulled threads together across all of that data. We made an ad for our chicken salt. It was great.
(Chicken salt. The audience loved this.)
Evangelism and Pushback
Liz: Have you ever had to be an evangelist? Or are you ever behind anyone else?
Daragh: We’re not regulated – we sell shoes and things, it’s all visible. I’m admin on everything and I can just enable things, so I’ve never really had to fight for it internally.
Dave: What I’m seeing a lot is that it’s often marketing or sales who think AI will magically make their life easier – and maybe it can – while the tech teams and product and design people are pushing back. And when you dig into why, it’s obvious: they have tight deadlines and no time to experiment. The CTO wants AI-first everything, but they haven’t set up the conditions for that to work. You can’t just hand someone a $20 licence and say “experiment, but don’t miss any deadlines.” The process changes, the workflow changes – people need space to learn that.
Melissa: I’m actually the constraint-maker in our business. I’m the one slowing things down, asking: are we solving the right problem? What are the constraints? We’re a small team, and my colleagues are even more enthusiastic about this than I am – but if we need to stop and rethink rather than keep going in the same direction, that’s encouraged. You need a really supported team and aligned incentives for that to work.
From the Audience
On arguing with agents
Audience member: I find it useful to say “don’t do this again” – because it stores that and it doesn’t happen next time.
Dave: That’s a really good point. The mental model is: I’m training this thing to create better conditions going forward. Not literally training, but steering. What I was talking about is more when it misses something in the middle of a task and I find myself swearing at it – which is fun, but doesn’t help.
On deterministic vs. stochastic decisions
Audience question: Do you have a conscious process for deciding what should be deterministic code versus what goes to the LLM?
Melissa: This is architecture 101, and it’s increasingly important given how token pricing is evolving. You have to assess how deterministic the outcome needs to be – is it customer-facing? What industry? Does it involve sensitive data? There’s a spectrum from a fully deterministic, orchestrated workflow through to autonomous, goal-based, multi-agent reasoning. I personally spend a lot of time at the deterministic end – the LLMs are used for things they’re genuinely good at: generation, judgment, working with messy data. Everything around them is code, harness, and structure. We started with more autonomous agents, swung hard the other way, and now good frameworks are emerging that let you move back toward goal-based reasoning while still having visibility and control over what’s happening. The most interesting question for me right now is: how do you build agents that are genuinely trustworthy? I don’t think that’s been answered well yet.
Dave: One thing I’d add: you don’t usually have to think about the cost of an individual request in traditional product development. It’s approximately zero. Now it’s not. From a product perspective, if you’re building AI products, you have to understand whether this is going to be a problem for your margins.
On shared context management
Audience question: Individually, I’m converting a lot of context into markdown files. But I’m part of an 850-person organisation with many PMs all in their own local environments. Has anyone cracked shared context management?
Dave: It’s something I think about but don’t have a good answer for yet. We use Notion, which helps, but it’s not perfect. I have delusions of restructuring everything properly, but that’s not happening soon. The interesting question is: how do you get information into a structure where people can see the benefit of contributing to it?
Dave (continued): There’s a fuzzy but real boundary between personal context and organisational context. Same with skills – the immediate instinct is to share everything across the team, but I actually think that’s often an anti-pattern. People develop their own skills, know how they work, know how to use them effectively. Sharing too broadly can dilute that. Some context should be team-wide; some probably shouldn’t.
Melissa: We’ve turned context into a repo. Backend, frontend, and the repo itself as context. For shared context, we use version control – submitting a PR to update context, which has a governance layer built in. Everything is versioned. We share all our skills, everything goes through engineering processes. It’s interesting how many layers this has – what’s local, what’s shared, what’s in a vector database, whether you’re fine-tuning a model. Different strategies depending on what the context is for and how you need to access it.
Daragh: The danger is that if you’re the person who owns this, suddenly everyone’s coming to you all day and you have other work to do. And telling people how to do things rarely ends well. What I’ve found is: make people jealous of what you’re doing. Circulate outputs. Show the value. Let people come to you asking “what are you doing?” rather than mandating a process from the top.
On expanding your skills beyond your role
Audience question: People in product and engineering are starting to do things that sit outside their traditional role – writing code, making design changes. Where does that work well, and where does it cause friction?
Dave: I’ve seen friction in organisations where roles are smearing. I wrote some designs but is the designer happy with it? I wrote this code but are the developers happy with it? There are real human challenges when no one has communicated whether that stretching is sanctioned. People don’t know what their role is, and leadership often doesn’t know either – because no one at any level of the organisation has figured it out yet.
Liz: Our roles have changed, but we haven’t necessarily realised it yet. “That’s my role, that’s your role” – those boxes might already be outdated language.
Melissa: I walk around with what feels like split personalities – I have both an engineering and a product mindset, and they approach problems differently. There’s a natural tension between them. I wonder: if you don’t have the metacognitive awareness to know which hat you’re wearing, is it too easy to be led by the AI or external forces in a direction that loses the productive friction that tension creates? That tension often leads to better outcomes. Smearing – [laughter from the room] – might actually reduce something valuable.
Daragh: Process creep happened before AI. With AI it’s just going to go faster. Everyone optimising locally doesn’t necessarily make the whole system better.
On staying in the loop vs. letting it run
Audience question: I’ve been building prompts and augmenting my skills for three years. I always imagined automating more and more, but I keep wanting to stay in the loop because any response could go the wrong direction. Am I thinking about this wrong?
Dave: The best harness for a coding agent includes an engineer. Ideally an experienced one. It’ll make trade-offs it doesn’t know are trade-offs – UX versus security, scalability versus cost. You’re responsible for those decisions. You can get it to work autonomously if you plan seriously: maybe an hour to an hour and a half of upfront planning for a sizeable change, and then it’ll go away and work for a few hours and get something close. But you’ll still iterate. The human still has a huge role. It feels like we’re close to full autonomy if you squint, but I don’t actually think we are.
Melissa: What’s interesting is: imagine if we set up our human team members for success the way we’re now starting to set up AI. A new engineer joins, looks at the codebase, reads the README, and has no idea what’s going on. But now there’s real motivation to document things well – because the AI needs context. Documentation is becoming part of the CI/CD pipeline. That’s a side effect I didn’t expect.
On evaluations and model stability
Audience question: What’s your evaluation strategy, especially with models changing and updating underneath you?
Melissa: It’s not that different from traditional engineering. You start with “what does success look like”. You break that down into discrete, quantifiable metrics, which become your test cases. For non-deterministic parts of the system, a simple pass/fail string match doesn’t work – you’re testing for intent, quality, tone. We use synthetic test cases, human reviewers to establish ground truth, and LLM-as-judge depending on the architecture. It’s always multi-layered, and it always starts with: what are we trying to achieve?
Dave: We’ve seen models change in ways we didn’t ask for. We watched one model get noticeably worse at coding over a period of time – apparently because resources were pulled to train the next version. We’ll have things just suddenly start failing with no changes on our side. That’s why running regression suites regularly matters. It’s not that different from any dependency that can silently change on you.
On model portability and architecture
Audience question: How much do you think about building products that aren’t tied to a single model or provider?
Daragh: Everything is built to jump ship at any second. There’s no loyalty to models. If a new one comes out in the morning, we’re ready to move.
Melissa: We’re model-agnostic but deliberate about choice. Different models are better for different things – some are great at JSON schema validation, some are better for generation and imagination. Token costs and prompt engineering differences between providers are real: a prompt that works beautifully with one model often needs significant reworking for another. Once cost becomes a real constraint – and it’s getting there – you’ll need to invest proper time in working out the minimum viable model for each job.
Dave: One nuance: if you want personality from a model, that’s where it gets hard to port. If it’s behind the scenes and nobody sees it, you can often swap models around fairly easily. If users interact with it directly, the personality will differ and your prompts will need fundamental rethinking. Also worth noting: with Claude models, capitalisation in prompts works well. With OpenAI models, it tends to push things too far. These are the kinds of differences you only learn by doing.
There’s also the “bitter lesson” thinking from the Bay Area – the idea that you want to benefit from future improvements to models, and the best way to do that is to describe the outcome you want rather than giving very detailed instructions about the process. That way, when the next model is smarter, it naturally does a better job. If you’ve over-specified the process, you’re locked into an approach that might not transfer.
On security, PII, and prompt injection
Audience question: What level of thought are you giving to things like sensitive data, PII reduction, prompt injection, tool poisoning?
Dave: Prompt injection and tool poisoning only matter if people are talking directly to the LLM. In our product, nobody does. It’s all behind the scenes, prompted in fixed ways, with data we’ve verified. Indirect prompt injection – where data in the context becomes the attack vector – is real, but the base models are getting better at resisting it. The fundamental challenge is that the control channel and the data channel in LLMs are mixed. There’s no technical way to separate them fully. A lot of money has gone into solving this. If we haven’t found the answer by now, it might not be possible to solve it completely.
Melissa: It comes down to the harness. What are you actually passing into the LLM? What’s the minimum viable payload? We won’t pass sensitive client information – it gets abstracted out. Some agents don’t get permissions to send emails; that happens at the end of a verified process. Security has to be first in how you think about architecture: what’s the worst case scenario, and what do you need to control for?
Closing: What Should We Do?
Liz: What’s your advice to the product people in this room?
Dave: Because it’s an art, you have to understand the grain of the material. You have to know how things feel and what works. The only way to get that is experiential. There are no courses that can really teach this yet. You have to be doing it – at work or outside of work – as frequently as you can.
Melissa: I’m actually hopeful. There are parts of the product function that we won’t have to do anymore – the product ops, the ticket-writing, the traditional product owner work – and that’s a relief. So many PMs I speak to are stuck in the weeds and only get 30 minutes a week to do actual product strategy. That excuse is disappearing. But if everyone has access to the same tools and can spin up a greenfield product easily, how do we differentiate? That question doesn’t have an answer yet, and I find that genuinely exciting.
Daragh: I was someone who went into the terminal only when I was doing something I shouldn’t be doing. That was four months ago. Now I have two Mac Minis and I’ve set up an MCP server for my rooftop bar so the team can check bookings, schedules, cancellations. Some of these words weren’t in my vocabulary. The only difference is I just decided to give it a go. The distances between “I don’t know how to do this” and “I’m doing it” are a lot smaller than they look. Find something you’re personally passionate about solving – that’ll carry you through when it gets hard. Ask for help from your colleagues. And do it together – because as an empowered product team, you will go faster together.
The Thread Running Through All of It
If there was one thing the panel kept returning to, it wasn’t a tool or a framework or a model. It was the human stuff.
Who owns the shared context? Who decides which roles can stretch into which? Who gives product, design and engineers the space and time to actually learn new ways of working instead of just mandating AI-first and expecting magic? How do you preserve the productive friction between different mindsets when those mindsets are increasingly blending into one person?
None of these questions are new. They’ve shown up at every technology transition. But AI is accelerating the timeline and compressing the window to get ahead of them.
The honest answer from all three panelists was some version of: we don’t know yet, but we’re figuring it out by doing. There’s no shortcut to the experiential knowledge of working with these tools daily – what they’re good at, where they’ll go sideways, when to push and when to restart. The gap between “this seems impossible” and “I’ve set up an MCP server for my rooftop bar” turns out to be smaller than it looks, and shorter than you’d think.
So: find a problem you actually care about. Try something. Ask for help. And if you and a colleague are both stuck arguing with the same agent about the same thing – maybe the conversation you actually need to have is with each other.
Thanks to our host
InvestorHub is a Melbourne-based scale-up with the mission to make being listed a superpower. Our software allows listed companies in Australia and the UK to manage their end-to-end investor relationships, from their investor-facing website, a detailed investor CRM, analytics, and more. We’re hiring for Product Managers, Product Designers, Engineers and more right now!
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
There’s a famous psychology experiment where dogs were trained to distinguish between a circle and an ellipse. Reward the circle, shock the ellipse – simple enough. Then the researchers slowly began warping the shapes, making the circle more elliptical and the ellipse more circular. The dogs handled it for a while. But eventually, when the shapes became indistinguishable, the animals didn’t just give up. They became frustrated, confused and aggressive.
It’s a striking parallel for what happens inside organisations when teams operate without clear direction. Conflicting messages, moving targets, misaligned priorities – they don’t just reduce performance. They put people in a genuinely difficult psychological position. Creating strategic clarity and setting goals that are measurable and coherently linked is one of the most meaningful things a leadership team can do for the humans in their organisation.
That’s the real reason OKRs matter.
A Quick History
OKRs – Objectives and Key Results – trace back to the 1960s and Andy Grove at Intel. During an intense period of competition (most famously with Motorola), Grove realised that the only path forward was to get product, engineering and marketing moving as a single coordinated unit. The OKR framework was his answer.
Created by Intel in a move that led them to winning the original chip wars. From there the method spread through the venture capital world, particularly through John Doerr, who brought it to early-stage companies including Google. The framework’s association with high-growth tech startups cemented its reputation – but it has since travelled well beyond Silicon Valley. OKRs are now used in flooring businesses, logistics companies, financial services and large enterprises across industries.
OKRs Are Not Strategy
This is probably the most important distinction to get right before you start.
Strategy, done properly, begins with a clear diagnosis of a specific problem or challenge – not a vague aspiration. Richard Rumelt’s work on this is worth reading (both Good Strategy Bad Strategy and his more recent The Crux are excellent). A real strategy names a problem, states a guiding principle for addressing it and commits to a set of actions. Most so-called “strategies” fail this test. “We will deliver the best service and experience for our customers” could apply to almost any business in any sector. It’s not a strategy; it’s filler.
OKRs live one layer below strategy. If strategy is your flight path – your unique route from where you are to where you want to be – then OKRs are the discrete stages of that journey. The first stage might be getting off the ground. The next might be reaching cruising altitude. You’re not trying to fly the whole route in one OKR cycle; you’re making measured, sequential progress.
What an OKR Actually Looks Like
An OKR has three parts: an objective, key results and initiatives.
The objective is qualitative and inspiring. It articulates the problem or opportunity and gives the team a sense of direction and purpose. A good objective for a product team might be: Make our customers our biggest advocates. It’s clear, it’s energising and it suggests what kind of progress matters.
Key results are quantitative measures of progress toward the objective. For the example above:
Increase trial-to-paid conversion from 5% to 7%
Increase first call resolution from 75% to 90%
Increase referral rate from 2% to 3%%
These are not to-do items. They don’t describe what you’ll do – they describe what you’ll see if you’re succeeding. The distinction matters enormously and it’s where most teams go wrong.
Initiatives are the actual work – the features you’ll ship, the experiments you’ll run, the processes you’ll change. These live underneath the key results. A useful check: if your “key result” could appear on a project plan or sprint backlog, it’s probably an initiative, not a key result.
OKRs vs KPIs: The Most Common Confusion
OKRs are about driving change. KPIs are about maintaining health.
Think of it like a rocket ship. The OKR tells you whether you’re making progress on the journey – how far you’ve travelled, at what velocity. The KPIs are the dashboard metrics that tell you whether the rocket is healthy enough to keep flying – temperature ranges, fuel levels, structural integrity. You need both.
If a KPI goes red, you don’t just ignore it in service of the OKR. You address the problem – which may mean the OKR pauses or adapts. This is exactly what happened for many organisations at the onset of the pandemic: the health metrics shifted so dramatically that OKRs had to be suspended or restructured in real time. The same logic applies at a team level. A system outage means you stop shipping features and focus on getting the service back up.
One important corollary: OKRs should not be tied to performance bonuses. Research on performance-based incentives is fairly consistent – for knowledge work, tying pay to specific metrics tends to distort behaviour rather than improve outcomes. You want teams to stretch and take risks. If the consequence of failing to hit a stretch goal is a reduced bonus, people stop stretching. The exception is sales, where a baseline health metric (the minimum expected revenue) might carry a small incentive, while OKRs drive focus on new markets or strategic shifts.
What can be assessed in a performance context is someone’s advocacy for the OKR – whether they put in genuine effort, contributed to the team’s progress and pushed for the outcome even when it was hard. That’s a meaningful signal. Whether the OKR was hit isn’t, because good OKRs are inherently uncertain.
Align, Don’t Cascade
A common pattern – and a genuinely problematic one – is cascading OKRs top-down. An exec sets a key result, delegates it as someone else’s objective, who delegates their key results further down and so on. This is slow, bureaucratic and disconnects people from the underlying purpose.
A better approach is alignment. Leadership sets a direction – say, “this quarter is about conversion” – and explains the problems they’re seeing and the context behind the decision. Teams then set their own OKRs in response to that direction. A team focused on onboarding might address conversion differently from a team working on the trial-to-paid transition, but both are moving toward the same company-level goal. No delegation required. Just a shared understanding of what matters.
Some teams – finance, legal, compliance – may have goals that don’t connect naturally to the company OKR. That’s fine. Their goals are still valid. But it’s worth being clear that the company OKR typically takes priority and any team that does contribute to it is working on the most important thing.
Focus Is the Point
The value of a good OKR framework isn’t just clarity — it’s the discipline of saying no.
One company Tim works with went from seven OKRs to one. When they had seven, almost none of them were being hit. When they got to one, they smashed it. The number matters less than the principle: the more things you treat as equally important, the less capable you are of making progress on any of them.
OKRs work best when they create focus with autonomy — the team knows what outcome they’re chasing and has the freedom to decide how to get there. This is a significant shift from feature-delivery thinking, which tells teams what to build. OKRs ask instead: what problem are we solving, and how will we know we’ve solved it?
During the session, participants named the kinds of problems they were actually sitting on. One team was dealing with a story kickoff-to-production cycle that was taking far too long — the instinct to frame this as “deliver faster” is understandable, but the OKR version asks what outcome faster delivery actually produces, and measures that instead. Another product was seeing 70% of users landing on a page and immediately leaving — a clear signal that something in the onboarding or value proposition wasn’t landing, and a rich problem to build an OKR around. A third example: a team wanting to migrate customers from a legacy payment system to a new one before being forced to do so later — the kind of proactive change initiative where OKRs shine, since success is measurable (percentage of customers migrated) and the outcome matters more than the specific path taken to get there.
Leading vs Lagging Indicators
When choosing key results, the most useful metrics tend to be leading indicators — signals that tell you something is likely to happen — rather than lagging indicators, which confirm something that already has.
Revenue is the classic lagging indicator. It tells you what happened, not what’s coming. A leading indicator might be the number of qualified conversations happening, or the trial conversion rate, or how many customers are actively using a core feature. These are things you can observe now that predict the revenue outcome later.
The line between leading and lagging isn’t always clean. Customer satisfaction, for instance, feels like a lagging indicator (you can only measure it after an experience), but it’s actually a leading indicator of retention. The useful question is: what can I measure today that will tell me whether we’re on track for the outcome we care about tomorrow?
Stretch or Commit?
There are broadly two schools of OKR philosophy: committed goals (things you’re confident you can hit) and stretch goals (sometimes called “moonshots,” where 70% achievement would be considered a success).
The case for stretch goals is strong. They force a different kind of thinking. If your team believes it can acquire 100 new customers this quarter, asking what it would take to acquire 1,000 produces a fundamentally different conversation — different levers, different partnerships, different trade-offs. That kind of thinking is where real innovation tends to happen.
The caveat is that stretch goals only work well when they’re psychologically safe. If missing a moonshot leads to consequences for individuals, people will stop shooting for the moon. This is another reason to decouple OKRs from performance reviews in the traditional sense.
Committed goals have their place when compliance or regulatory requirements make the outcome non-negotiable, or in rare organisational contexts where building confidence with achievable wins is genuinely the right starting point. But for most teams doing knowledge work, stretch is the right default.
OKRs in the Wild: Workshop Examples
The best way to see how this works in practice is to watch real problems get shaped into real OKRs. Here are a few that emerged from the room.
Building an AI advisory practice. One participant was launching an AI strategy consultancy and wanted to establish credibility fast. His objective: become a reference customer in the space. A first instinct for key results was “have five conversations with potential clients” — but that’s an initiative, not an outcome. You can have five conversations and get nowhere. A better key result might be the number of paid engagements secured, or a signed reference client by end of quarter. The initiative (having those five conversations) sits underneath it. The distinction matters because it keeps the team honest about whether the activity is actually working.
Migrating customers to a new payment platform. Another participant’s team had built a new payment solution and needed to move customers across before the old one became a liability. The OKR structure here is clean: the objective is something like proactively transition customers to our new payment experience, with key results measuring the percentage of customers migrated and perhaps a satisfaction signal from those who’ve made the switch. The initiative layer covers the communication sequences, in-app prompts, and support workflows that make it happen.
Increasing adoption of a legacy platform. A team working on a product that needed to be integrated across a number of external companies framed their objective as doubling adoption. Their key results included a 30% increase in data sharing through the platform and a doubling of self-service interactions. The feedback from the room was useful: “double” is directionally right but needs an anchor — double from what, to what? Pinning the numbers makes the key result testable and gives the team something concrete to report against.
What these examples share is that the problem came first, and the measurement followed from it. That’s the right order.
One of the most common failure modes with OKRs is treating them as a quarterly planning exercise rather than a living practice. Setting OKRs and revisiting them only at the end of the quarter is almost guaranteed to produce drift.
Good OKR practice involves check-ins — weekly or fortnightly — where teams look at their key results, ask what the numbers are telling them, and decide what to do next. Even badly written OKRs tend to improve over time when teams review them regularly. The review process itself surfaces what’s working and what needs to change.
This is also where OKRs connect to broader frameworks like 4DX or similar execution methodologies — not as replacements, but as the structural ceremonies that keep the goal visible and the team honest about progress.
OKRs aren’t complicated in theory. The challenge is doing the work to get clear on what actually matters, building the habits to stay focused on it, and creating the kind of safety that lets teams genuinely strive for something ambitious. When that comes together, the results tend to speak for themselves.
Tim Newbold Profile
Tim Newbold is an OKR Coach, Product Operating Model Coach, and Founder of OKR Quickstart. He helps software product businesses turn strategy into measurable results, including 30%+ quarterly sales growth at Domino’s, 88% work visibility gains at MLC Life Insurance, and full OKR target achievement at Titan FX. Clients include SEEK, Carsales, Scalapay, BAE Systems, Inteleos, and Foundr. Based in Melbourne, Australia. Available for coaching, consulting, and keynote speaking at hello@okrquickstart.com.
Our Host:
David Jones As one of Australia’s most iconic retailers we have a rich 185-year history of being a curator of world-class brands. Our people are driven by the passion and desire to inspire our customers with seamless service and experiences like no other.
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.
If you are looking to change jobs or looking to hire, right now is an interesting time! We’ve been hearing ‘product is in demand’, there’s an impact on salaries and OMG! It’s the ‘great resignation’.
But what is really happening out there? We have a panel of folks in the thick of it to help understand what’s really happening.
Join us to hear what’s really affecting how they hire, what’s the same and what is changing and ask your questions! This is an Ask Me Anything (AMA) format. This is for both folks looking to hire and those looking for work or ‘open to opportunities’. We’ll be using slido for questions (#hiring) and it will be a hybrid session – so folk are welcome at our host location and online. RSVP now.
Our Speakers
Megan McDonald, Head of Product & Experience Design at World Vision Australia.
Megan has been working in Product roles for over 15 years, and over this time has experienced first-hand the exciting transformation of the role of product in organisations. She’s very ashamed to admit that in her early days as a fin services Product Manager she built products that were designed to extract revenue by limiting customer value .. yep, on purpose! But, in the years that followed, she’s also super proud to have been involved in the evolution of product into the truly human-centred practice it is now.
Megan is a passionate believer in the value that good Product Management can deliver to organisations and their customers, and is busy putting “my money where my mouth is” as a council member of the Association of Product Professionals, working hard to advance the product profession.
Day to day, Megan leads the Product & Experience Design function at World Vision Australia, and an amazing team focused on delivering Australia’s favourite charity experience. “I feel so lucky in this role because I get to solve real customer problems by building sh*t that works, all in the service of eliminating global poverty. And at the same time, I’m helping to create the next generation of product and design thinkers and practitioners.”
Georgia Hart, General Manager, Middleton Executive
Georgia moved to Melbourne roughly 5 years ago with just $200 in her pocket after spending her travelling budget way too soon (oops!). She found myself back in recruitment, learning the Australian landscape and quickly found that there are a lot of very cool start-ups and companies creating a big impact in the world. Georgia had traditionally always recruited Engineers with a little bit of Delivery & Product on the side but wanted more of it so joined Middleton Executive. Middleton Executive is a talent partner of choice for some of Australia’s most eminent tech and product companies and was founded to connect people in the product space. She’s had the pleasure of working with some awesome brands such as SEEK, Whispir, Papercut and is learning from some of the best product leaders in Australia. Big shout out to them for teaching her so much!
In her own words “There’s no denying that the last 2 years have been a rollercoaster. In March, all my clients stopped hiring, people were losing their jobs, it was sheer panic. I found myself out of a sales role and in more of a position to support people navigate through the unknown. 2 years on and here we are, in the busiest market I’ve ever found myself in and having to learn new skills to attract the most in demand talent.”
Shiyu is an experienced Product Manager with 5+ years of experience in building product roadmaps and shipping features in an agile environment. She is problem-driven and likes to take a customer centric approach in every product feature to make sure it has an impact and solves for a real customer problem. Currently hiring at Zendesk, Shiyu has some key learnings about how the organisation has had to make adjustments in their approach in the current climate.
Our Host Intelligence Bank
IntelligenceBank is the leading innovator in digital assets management and marketing operations. The company helps marketing teams seamlessly manage digital assets, creative content approvals, marketing compliance, and creative project management to ensure brands get to market quickly, stay on brand and ensure regulatory compliance. IntelligenceBank’s beautifully designed platform is used by over 400 brands with 500,000+ users in 55 countries. IntelligenceBank has offices in the U.S., Canada and Australia. Follow them on LinkedIn
Creating Buy-In: how to foster cooperation and shared commitment to ideas and initiatives.
So much of what we do requires the cooperation and commitment of others. Getting others onboard isn’t simply about getting projects across the line. It’s about harnessing the full creative potential of teams and fostering a culture of shared ownership and accountability. This requires a careful balance of positive influence, while at the same time allowing plenty of space co-creation.
In this practical session, Simon introduces his ‘3M’ framework for generating positive influence and explores the most common pitfalls of building buy-in and how to avoid them.
Our speaker:
Simon Dowling – is a leading thinker on creating and leading collaborative teams and workplaces. As a speaker, facilitator and educator, he works closely with leaders and teams from some of Australia’s most interesting organisations, equipping them with the inspiration and know-how to build strong, highly engaged teams.
Simon possesses a unique blend of creativity and pragmatism – something reflected in his past experience. He began his career as a commercial lawyer, and is also an experienced improviser, regularly performing with leading improvisation company Impro Melbourne. He was a regular cast member on Working Dog’s hit TV show Thank God You’re Here. For the past 20 years, Simon has been working with leaders across a wide range of industries, helping them to tap the collective genius of their people.
His clients include AFL, Bega Foods, Bendigo & Adelaide Bank, BUPA, Envato, Mercedes Benz, myob, SEEK, Telstra Health and University of Melbourne. He is also a member of the Australian faculty of DukeCE – the executive education arm of the internationally acclaimed business school at Duke University.
Have you ever felt like your life has become all about juggling the priorities? And you’re just on this hamster wheel…
Phoebe Peck has been on that wheel – and knows you need to stop. From juggling near term to long term priorities, Phoebe will be share tried and tested strategies for running in a straighter-ish direction while recognising detours, temptations and pitfalls along the way.
She will share her experiences on prioritisation including from a lighter perspective because let’s face it if we don’t laugh we will cry! (or go insane…)
Conversation & sharing of your tips will be encouraged!
About Phoebe: Phoebe Peck is passionate about hospitality, technology, people and leaving positive imprints on the world through the decisions we make and the actions we take.
Phoebe is Head of Product for the industry-leading hospitality SaaS Company, Redcat. Her talents in product and technology have greatly benefited from a strong operational and managerial background in best of breed quick-service restaurants, and fast-casual hospitality business.
Phoebe values teamwork, perseverance, work ethic and honesty. Phoebe attributes her professional success to her internal drive, continuous learning and working with amazing people.
Phoebe lives in the heart of Tigerland, is a mother of 2, is very competitive, always up for a challenge and has ambitions to one day present at TED.
