Discovery is incredibly important though there’s a lot of ways to do discovery – so what’s the right way to do this? Or do you really need to do discovery?
Our speaker, Melissa Klemke, Head of Product at Prezzee, will take you though an interactive session and will be covering a lot including:
Types of research
Working with User Researchers (if you have them & what if you don’t)
Setting up a research program and customer pool
What market research is useful and how to do it
Forming hypotheses
Experimenting
Tooling (with and w/o fancy tools)
Solutioning & technical discovery
Our Hosts:
At Propel, we’re dedicated to helping businesses achieve sustained product success. That means not only bringing your product ideas to life, but also ensuring that they remain relevant and successful over time. With our unique blend of software development and product strategy services, we offer a comprehensive approach that goes beyond just delivering a product. Our goal is to help you create long-lasting results that drive growth and success for your business.
Founded in 2016, we are a team of entrepreneurial product strategy, design and development leaders with a track record of building businesses, creating and expanding markets, and developing new technologies that benefit millions of people across the globe. https://www.propelventures.com.au/
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.
Or maybe the question is – do you think about your value prop? How do you communicate your value prop?
This month we’ll organise you into small groups to do a bit of a workshop. We’ll have an exercise that might mean you need to bring your own paper and scissors to help you think about your products value proposition. Jen + Liz + Steve B will be your fabulous fun hosts.
NOTE: We have some stationary from Product Camp but if you have your own sharpie to bring, that would be helpful! Sharpie colours are good!
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.
Upgrade your product delivery with OKRs (Workshop)
One of the best things we can do as Product people is get our teams excited about solving real customer problems and measuring success. We’re going to cover just that in this session, we’ll explore how to go from strategy and discovery, to validating the impact once launched with the Objective and Key Results (OKR) framework. A goal setting framework used by some of the world’s leading product businesses, like Google, LinkedIn and SEEK. This will be a practical session, so be ready to work on your product!
Our Speaker:
Tim Newbold, OKR Coach and founder of OKR Quickstart will be our speaker. Tim founded OKR Quickstart to help tech companies unlock growth. They do this by creating focus on the biggest growth constraint, getting the team behind the plan to solve it and delivering meaningful results. He has a background leading product engineering teams in SaaS and Fintech businesses. Tim loves to work with some of the worlds leading tech businesses, such as ELMO Software, Domino’s, SEEK, Carsales & Connective.
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!
As software companies scale and the product team grows, the difference between building ‘stuff’ and performing the practice of product management can be massive. It can greatly impact the ability to find product market fit through to the ability to scale with pace and grace.
Our speaker, Nick Wodzinski, has worked at several start-ups and shared his first hand experience of moving the team into the practice of product management while being resource constrained.
Nick’s 3 tips are:
Think about roles, not job titles
Nick shared some previous conversations that helped to shape this guideline including talking to a founder about Marty Cagan’s idea that each team should have a product person and the founder saying they can only afford him – the one product person. Or having to do some UI and design work although he’s the product person and wondering if he really should be doing this (although there’s no designer at the company).
In order to solve this, think about the role, not the job title. Get comfortable, especially in startups, that someone who might not have the training is going to be doing a specific role. And the person doing that role may change over time. The person doing that role might even be different for different areas of the product. AND this is ok.
If you find yourself in this situation, be clear on who is responsible for each thing. Have a conversation about who will play each role so everyone knows what is expected of them and who is responsible. Having some sort of indicator is also helpful – a hat, an emoji, listed on the wiki page, etc.
Ever had a founder or exec approach you with an idea they got from a competitor’s webinar or something their friend told them about (the old ‘airplane magazine syndrome’)? The person telling you about this and asking why you aren’t working on the same is coming from a good place – a place of trying to keep the company afloat – though these conversations can be distractions to the strategy.
You want to have a productive conversation that doesn’t create tension between you & this person. You want to frame the outcome for the business and the team, not talk about how important the discovery is.
Nick referenced a talk by Kirsten Mann at LTP where she talked about executives want certainty. You might feel like showing your work will help them understand but really you want to remove the language of product & design from these conversations and focus on the commercial acumen – what is the expected impact?
Another way to frame this comes from General ‘Salty’ Saltzman from the US Space Force. He wants to know what is your theory of success. You should be able to tell someone what you’re trying to achieve and how it will help achieve success.
Nick suggests using the language of ‘bets’ to get out of our jargon and move more towards risk, portfolio of bets and that losing might be an option. This also helps to move away from the conversation of when something will be delivered but should we back other bets or continue to continue to back this bet based on the data we have gathered. He then shared a great conversation he had at one company where ‘getting to parity with a competitor’ was being encouraged and Nick asked what would the impact of ‘parity’ be? Would it get us every deal? No. Would it get us half the deals? What if we did something different that solved a real problem that could help us win more than half the deals? How long would we fund this bet? How long should it take us to understand this bet? This conversation led to a new strategy with a new market to sell to.
Managing your career growth if you’re the 1st (or only product manager)
You might have dreams for your product manager career – getting promoted, earning more money, whatever you dream of. That might not be the reality you work in. You might not get great feedback (keep doing what you’re doing!). There might not be the opportunity for promotions or not a clear idea of how that would ever happen (keep deliverying value says the boss). You probably gather your data from salary surveys and put forward your case but if the organisation doesn’t have the money, they can’t give you a raise.
This does not mean you can’t continue to grow! You need to create your own path. Nick is creating a growth framework for his team which explains the competencies for a PM at different levels.
Nick reflected on his own dreams of presenting his roadmap to the board right after starting his new job. He was advised by that 1st you need to show that you can present it to your team and that they understand the vision and how they contribute to that vision. If you’re doing well with the team, then the next step could be to present to the company at the next all hands. Think about what are the levels you can do this at and how you can stretch and grow.
Nick Wodzinski is the lead product manager at Chargefox – Australia’s largest public charging network for electric vehicles. His background is in construction tech, and he has worked setting up product teams with startups and scale ups over the last 5 years in the Australian software industry.
Our Host
Our wonderful friends at Everest Engineering will be our hosts for the evening.
Everest Engineering: A bold, people first community, building digital products for those who do things differently.
What is the difference between a product team building a product and product teams ‘doing product’? As software companies scale and the product team grows, the difference between building ‘stuff’ and performing the practice of product management can be massive. It can greatly impact the ability to find product market fit through to the ability to scale with pace and grace.
Our speaker, Nick Wodzinski will share his experience of going from product hire #1 in startups & scale ups and working with teams building product to setting the formula for growing from 1 to many product teams. Nick will reflect on his experiences of setting up teams over the last 5 years with SignOnSite, EstimateOne, Mastt and Chargefox.
Our speaker:
Nick Wodzinski is the lead product manager at Chargefox – Australia’s largest public charging network for electric vehicles. His background is in construction tech, and he has worked setting up product teams with startups and scale ups over the last 5 years in the Australian software industry. Fast 5 Q&Awith Nick
Our host: Our wonderful friends at Everest Engineering will be our hosts for the evening.
Everest Engineering is a bold, people first community, building digital products for those who do things differently.
As a product manager, have you gotten caught into the AI frenzy? Or feel like you’re missing out and not sure where to start?
This month we’ll talk about how to make use of AI and tools like ChatGPT in your product world. RSVP for September 21st
– How to use Generative Ai in your workflow, i.e. pad out a persona
– How to incorporate it into an existing product i.e. Shopify launching Sidekick, a personal commerce assistant
– What could you do to build from the ground up with chatGPT, as an example. i.e. this is the hardest to predict at the moment as well but we can explore some of the future opportunities
Our speaker:
Tim O’Neill is the Co-founder of Time Under Tension. They help companies make sense of Generative AI and how it can be used for their products.
Catapult exists to unleash the potential of every athlete and team on earth. Operating at the intersection of sports science and analytics, Catapult products are designed to optimize performance, avoid injury, and improve return to play. Catapult has over 400 staff based across 24 locations worldwide, working with more than 3,800 Pro teams in over 40 sports across more than 100 countries globally. To learn more about Catapult and to inquire about accessing performance analytics for a team or athlete, visit us at catapult.com. Follow us at @CatapultSports on social media for daily updates.
Take your mind back to August 2019.. it was a bit chilly and we had 300 people interested in product all together for Product Camp. We celebrated 10 years of Product Camp in Melbourne, where Rich Mironov virtually spoke to us about the importance of community and history of Product Camps, Georgia Murch helped us understand feedback, Antony Ugoni shared his knowledge and experiences with bringing the data and about 20 of our community gave talks (after they pitched & the attendees voted on what they wanted to hear).
AND then there was that thing – that prevented us from gathering together.
But we’re excited to say… we’re back. Join us on Saturday August 5th (RSVP)!
Same familiar ‘unconference’ style event where we organise the venue and keynotes (including Ken Sandy and one TBA) and make sure you have some food and water during the day – but you (!) are active participants! You can pitch a talk idea, or run a panel discussion or ask for a working talk to help you work thru a problem.
NOTE: If Camp is at waitlist, we recommend you add yourself and check back in. As the day gets closer, numbers will change and spaces will become available. If you are one of the people who have RSVP’d but something has changed and you can’t make it, please change your RSVP to no so others can attend.
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.
