Engineering + Product kicking ass together! – May Wrap

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. 


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. 


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!


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: 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 – is used by millions of customers. Check out our pride and joy to learn more about us and how we deliver amazing products and software!

What’s all this hiring hullabaloo? And interviewing stress? A panel AMA event

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 Zhu, Group Product Manager, Zendesk

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


October event – Creating Buy-In

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.

Simon is the author of Work with Me: How to get people to buy into your ideas

RSVP now!

Thanks to A Cloud Guru for being our online host. A Cloud Guru’s mission is to teach the world to cloud, and they’re hiring!

A Cloud Guru Logo

September event – Prioritisation: The ultimate hamster wheel

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!

See you on Thursday, September 24th RSVP

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.

A Cloud Guru Logo

Our sponsor: A big thanks to A Cloud Guru for sponsoring! Our mission is to teach the world to cloud. Find your place at ACG.

April wrap – Ten steps to lead through influence as a PM

Product managers are under pressure to drive results, but cannot wield direct power or authority to achieve their objectives. If you don’t know how to influence people at all levels of the organization, how will you create the best possible product?

In this talk, Ken Sandy shared ten techniques from The Influential Product Manager that product managers can immediately apply at each stage of the product life cycle to achieve the best outcome for the customer and their organization.

Key Takeaways:

1. Influence goes well beyond aligning stakeholder and team behaviours behind a common purpose – it is winning their hearts and minds through context setting, establishing a shared set of beliefs, and a passion to solve customer problems.

2. As a PM, being influential starts with how you view and approach your role – such as embracing and stress testing ideas, establishing collaborative relationships with stakeholders and decisively making prioritization and trade-off decisions.

3. Powerfully, product managers are at their most influential when they focus on owning and communicating the problem to be solved (enabling solutions to emerge collaboratively) and driving towards meaningful customer and business outcomes (over simply delivering projects).

Our presenter:

Ken Sandy is a 20+ years veteran in technology Product Management. Ken pioneered and teaches the first Product Management course offered in the Engineering school at UC Berkeley, which has over 400 PM alumni. Throughout his career, Ken consistently defined, launched and managed award-winning, innovative Web and mobile products loved by customers and used by millions of users across 60+ countries.

Previously, Ken served as VP of Product Management at leading online education companies, MasterClass and (Linkedin Learning), and is currently an executive consultant and advisor for startup and scale-up companies in the US, Europe, Asia and Australia.
​He’s recently released “The Influential Product Manager – How to Lead and Launch Successful Technology Products” a highly practical and approachable guide to becoming more effective and navigating the challenging collaborative aspects of the product manager’s role.

Ken’s book is on sale for a limited time: ($A paperback) or ($US ebook). If you are interested in having Ken do a talk at your company or just have some questions for him, don’t hesitate to connect with him at or on linkedin:

Here are the slides and the video for your viewing pleasure.

Click here to watch Ken's talk
Click here to watch the video of Ken’s talk

We had such a great time running our first talk online – we had folks pop in from other cities In Oz and countries as far as Brazil & New Zealand. It was really nice to welcome our friends from other cities.

Just like the f2f sessions, there’s always those folks who don’t know when to go home. 😉 Chatting after the session.

Thanks again to A Cloud Guru for hosting us online this month! We’re on a mission to teach the WORLD to cloud. A Cloud Guru is the largest online cloud school on the planet. Our training feels more like logging into Netflix or Spotify – it’s entertaining and playful. The people are the #1 reason employees say they stay at ACG. We’re a quirky, tight-knit crew that cares about our customers and each other. No egos here. Our leaders encourage thoughtfulness, compassion, being humble, and we have a bit of fun along the way.

September Wrap – Net Promoter Score (NPS): Science or Pseudoscience?

Over the years, Net Promoter Score (NPS) has become the default question to measure and maximise value. But is it right? Is it true? Daniel Kinal joined us to share his thoughts.

Where did NPS come from?
Back in 2003, Fred Reichheld introduced the concept to the world. He felt the current measures of loyalty were too convoluted and complicated. So he did his own study, with surprising results, even to him. What he came up with, Net Promoter Score – the one metric that was supposed to have the strongest correlation to company success.

Why should it work?
The more likely you are to advocate for a brand, the more people will be willing to trial the product, therefore reducing your acquisition costs. Also, those advocates are more likely to be repeat customers and increasing their lifetime customer value. Score. Double score!

Some caveats:

  • Simply irrelevant in some industries
  • Not predictive in a monopoly or near-monopoly conditions
  • Data analysed was historical, not future
  • Unconvincing replication studies.
  • Highly volatile measure
  • Obscures critical information

Is there a correlation? Well, yes. Is it good as a predictor for future success? Well, maybe not as much. In fact, in one study, NPS only explained 38% of future growth.

If you game your scores, what do you really achieve? From colour coding, nudging your scores, and filtering out negative results. What are you actually able to learn?

Is there an upside?
Yes, some compelling aspects of NPS include, it is relatively cheap, fast, simple; and well accepted.

Already using NPS? Make the most of your data.

  • Don’t focus purely on the number.
  • Measure brand or full product experience rather than feature or interaction
  • Measure longitudinally and conduct trend rather than a point in time analysis
  • Keep it as scientific as you can (randomisation, third party research)
  • Compare your NPS to direct competitors
  • Remember what you are measuring (loyalty and propensity to evangelise, not product satisfaction).
  • Analyse the qualitative feedback
  • Collect actionable data too, such as customer satisfaction.

For a shorter version of Daniels’s talk please find this recording from his presentation at Web Directions. Here are the slides from the evening.

Thank you to Medibank for hosting, and all our Prod Anon volunteers for helping on the night, Nadia Gishen, Irene Toh, Marija Becker, Yau and Steve Cheah for this write-up.

June event: Continuous Discovery – Worth the effort?

Most teams have gotten really good at delivering quickly, and measuring our results. However sometimes we can get a bit addicted to shipping fast rather than right, listen to our assumptions too much, and relying on A/B testing to validate if we’ve delivered value.

Hear about the struggle and joy of a journey of continuous discovery, and some examples of validating ideas before building anything.

Our presenter:
Caitlin Blackwell is Acting Head of Product – Candidate Experience at SEEK. She’s previously been in Product Manager roles across many parts of SEEK over the past 7 years, and is currently focused on driving the candidate vision for all of SEEK’s jobseeking products.

Continuous Discovery

Teresa Torres defines Continuous Discovery as weekly touch points with customers, by the team building the product, where they conduct small research activities, in pursuit of a desired product outcome.

That sounds easy but it is a lot of work to adopt if not already a habit. Some of the mindsets needed to do this well are:

  • A collaborative mindset: Do you have the right people involved in each decision?
  • A continuous mindset: Are you continuously discovering opportunities and solutions?
  • An experimental mindset: Are you prepared to be wrong?

Teresa Torres has another great video explaining the value of continuous discovery and where it fits in with the many other methods we may be using already. Join us this month to hear more about what it takes to implement and the benefits to be gained for you and your team. RSVP now

Thanks to our wonderful hosts RMIT Online.

Launching Australia’s first University program in Product Management on the 1st of June to help fulfil the emerging skills gap in product management! It’s a Graduate Certificate – Masters level, 4 subjects, and can be completed in 6-12 months.

May session – OKRs in Real Life

This month we will be talking about OKRs – aka Objectives & Key Results!

This is a follow on from our Roadmap discussion in February where some of the frustrations with roadmaps could potentially be addressed by working with OKRs.

OKR’s have been around awhile now, but are somewhat relatively new for product teams here in Oz. We have gathered a few folk who are actively using them, to share the pain and the success of getting started.

Our presenters will be:

  • Andrew Knibbe, Head of Product – Direct Hirer at Seek – has over 10 years of product management experience – cutting his product teeth in the early days alongside the ThoughtWorks team at Sensis followed by stints at Carsales and Flippa before moving to SEEK where he has had Head of Product roles across both the Consumer and Business side of the employment marketplace. He doesn’t miss the chevrons-on-a-page days of product roadmaps and remains excited about what OKRs can mean for product teams (and customers!).
  • Wayne Allan, Technical Product Manager, REA – A muso turned software engineer turned product manager, I love creating things people love! Currently solving problems at
  • Brad Dunn is the Co-founder and Product Director at OHNO in Melbourne. Before that, he was the executive for Product & Customer Experience at Geo. For 7 years, Brad was the CEO of Nazori, a mobile product development business, where they worked with clients in 12 countries around the world including Samsung, Airbnb and Aesop.

For some pre-reading to get you across the area if you haven’t heard of them or used them yourself then try these resources:

Thanks to our sponsors Medibank for being our hosts this month. RSVP now.

We are Medibank – an integrated healthcare company providing private health insurance and health solutions to 3.7 million Australians through our Medibank and ahm brands, and complimentary health services.

We also provide a range of integrated healthcare services to our private health insurance policyholders, government, corporate and other retail customers. With over 3,000 employees, our head office is located in Melbourne, Victoria, with operations nationally throughout Australia.

By delivering on our promise, for Better Health for Better Lives, we work better as individuals, better as a team and better as a business.

F**k Roadmaps!!! – The good, the bad and the ugly – The wrap-up

We opened 2019 talking about roadmaps – a topic we had been asked in responses to our annual feedback to spend some more time on. We invited our speakers to share their different perspectives on roadmaps… and we heard come common themes to help understand how to keep a roadmap from controlling your life, and how to turn it into a fabulous communication and vision guide for inspiring your teams, plus some sage advice relevant to each organisation who took the stage that evening.

Below are some highlights from each talk plus the slides from each speaker – feel free to reach out to any of them if you would like to chat more. Plus we have added some references to other resources to read and explore at the end of this post.

David Bignall / Seek

David had much to share – ultimately not a fan but he did share some tips on how to help make them work for you rather than be a slave to them!

Roadmaps are a thing, every company has them so you will encounter them. David used this deck at Seek over a year ago to his team and people so proof they are a real thing, but after having the discussion has helped wean the team/group he is on off them.

For David when sharing what he thinks a roadmap is showed a map – because it is a journey to an unknown place.

“A document to capture and quickly convey a team’s big-picture goals, specific objectives and their imagined path to success” – Dave

 “A company roadmap is a document to capture and quickly convey its big-picture plans and objectives” –

“The first purpose is because the management of a company wants to make sure that the teams are working on the highest value items first, relevant to the company strategy.

The second purpose is because businesses may have date-based commitments. The roadmap is where they see and track those commitments.” Marty Cagan, SVPG

They can be useful – but they can also be a big waste of time – common issues:

  1. Intended goals/purpose are not stated or are not clear
  2. Often far to specific
    1. You can’t have that much foresight 9 months away
  3. They do not account for “time to value”. Iteration is almost always needed to realise the full value of a new product/feature – (David bravely shared an own example of a very bad roadmap!)
    1. Put item on there and them immediately moving on to the next thing
    2. Ignoring the process of iteration or things going wrong
  4. Detail on roadmap can lead team to auto-pilot. They build what they put down on paper often months in advance
    1. Team goes into auto-pilot. As if this is their job, rather than thinking of most value to be delivered for the customer
  5. Distributed copies are out of date
    1. Keeping stakeholders up to date can drain your time. You don’t want to feel like you work for the roadmap, and it is just sucking your time from doing real work.

“Many untested hypotheses, based on assumptions, plotted in an uncertain future, bearing no resemblance to reality” Jared Spool

Dave’s top tips for roadmaps

  1. Show where you want to go
  2. Choose granularity relative to the timeframe and audience
  3. Avoid specificity (Show the problem or JTBD or objectives as descriptors of intent rather than the solution)
  4. Keep it simple, centralised and accessible
  5. Don’t work for it, it works for you.

Whitney Cali /

Whitney opened with sharing a story about her experiences of not liking roadmaps because she has never seen a roadmap, become reality. She first got to know REA when working at a company in the US, and became a slave to the roadmap as they committed to work they would deliver to this customer. Then, she joined REA and was so excited about agile and thought, YES! I’ll get away from roadmaps! But she was fooling herself – see the beautiful roadmap on the wall at REA (pictured in slides). However, she soon found that REA was using roadmaps and needed to due to the big size of the organisation and the need to coordinate a lot across so many teams, groups etc.

However, in Whitney’s attempt to accept roadmaps and make peace with the need for them she started asking “Why do people ask for roadmaps?”.

Some of the things she learnt don’t work when using them:

  1. Don’t work as a promise
  2. Too much detail – just a list of lower level features
  3. Lose focus on what the customer needs.

REA owns a lot of companies and even just within a dozen delivery teams.

“Satisfaction is a confirmation or dis-confirmation of expectations.”

Example of people waiting for train for 15 minutes but dissatisfied, and others warned that train will come at 5:30 and apologies for the delay, did not rate their travel experience as dissatisfying as compared to the first group as their expectations were met/managed.

With that in mind let’s try to think what this artefact does to satisfy our leaders.

So what are they currently doing with Whitney’s team – they use a 90 day view – showing a commitment up to 90 days. No promises beyond that – great for delivery teams. Not great for stakeholders.

For stakeholders they use a Discovery backlog (second 90 days) and an Opportunity backlog (all the rest – no priority) – people now satisfied that their idea is on there – somewhere. Others groups understand that stuff that comes out of Discovery will most likely make it to the committed version and the conversation is being moved to a different stage of team flow.

I encourage you to seek to understand with genuine curiosity, the needs of anyone who has a problem and thinks that a roadmap is the solution. Whitney

Keith Swann / Origin Engery

Keith brought to us a more positive upside to the roadmap discussion

His beliefs are that they help with:

  • Alignment – up or down
  • Influence – rarely based on dollars
  • Leadership – how do we inspire people and rally them to our cause


  • Everyone will scrutinize it to their own beliefs, so do it carefully – target on your back
    • Strategic – Financial, PMOs, GMs, etc. etc. interpret the stuff and then try to manage up and down.
    • Cultural – make sure it talks to your audience
    • Influence Record – Successful record of moving things along. Better record = less scrutiny

A road map is a Story telling device and the aspects Keith uses are MUM, Problems, Position, Opportunity, Value. How do you tell the story, “up or down” the organisation. Think of the “Cone of influence” – below people can make lots of small decision but not big decisions. As you move up you get spun out if you aren’t managing those stakeholders.

  • Eisenhower: Plans are useless, but planning is indispensable
  • Every day the plan can change – the second your plan is finished it is out of date.
  • Roadmap = Vision.


  • Don’t put in too much detail
  • Think of your audience – Working Tested Feature – WTF
  • Don’t muddle the Project Mindset – Delivery Planning – Bookending with a roadmap
  • Don’t become vague in your horizon 2 and 3 – don’t over promise
  • Make it easily editable and manageable
    • Post Its on the wall and photos
  • Over invested time of effort – working with visual designers. 5 days work and 6/7000$ and printed in colour. Thus, you deliver to the roadmap even though you don’t want it anymore because too much effort went into the artefact.
  • Don’t clearly show values
  • Don’t focus on the feature – focus on the problem or opportunity.


Roadmaps may very well be a necessary evil, especially in a big organisation when you have many teams and people to motivate, inspire and align. However, our speakers have shared some great tips to help keep you from being a slave to them as well. For some more references and reading on steering clear of them and/or leaning into making them work for you check out some of the links below:

  • Brad Dunn has some opposing opinions on roadmaps.
  • Marty Cagan is not a fan and in these post he links to OKR’s which came up in both the speaker presentations and the questions afterwards.
  • And last but not least for a more practical tuition on taking back control of your roadmap you could check out Bruce McCarthy’s seminar on UIE

Thank you!!!

And thank you to our sponsors as always, without them these events do not happen.


F**k Roadmaps!!! – The good, the bad and the ugly

Welcome to 2019!!!

For our 1st session of the year, we are focusing on the #1 requested topic in our annual survey – roadmaps!

Our speakers will be taking you through their perspective on roadmaps… we won’t give it all away just yet but you will hear that not every roadmap is f**ked, tips on how to unf**k your roadmap, and of course when to tell a roadmap to go f**k itself.

Our speakers will include examples from both personal experience and the way their current organisation navigates their use. Our three great speakers will be:

David Bignell

  • Product Lead at SEEK, currently focused on improving the eCommerce space across the APAC region.
  • Picked up most of my craft from stuffing things up at least once.
  • Current ‘product passion’ would be trying to describe things in verbs and not nouns. Gives an interesting perspective!

Whitney Cali

  • GM Product, Audience & Experience, REA Group
  • As REA Group’s GM – Product, Audience & Experience, Whitney Cali is responsible for creating smart and compelling experiences in’s desktop & mobile apps to help change the way the world experiences property. She leads a team of product managers, designers and UX researchers to create intuitive and personalised experiences that help individuals make great property decisions.

Keith Swann

  • Lead Product Manager, Origin Energy

There will be lots of time for Q&A and you can submit questions via or vote on the questions of others. Details will be shared on the night.

Thanks to our sponsors! Without them these events would not happen!

Thank you to Gather for hosting us. Gather is a brand within United Co. and exists to connect and inspire a community of Melbourne’s bright-minded and open-hearted, exploring complex questions, expanding perspectives and building skills for a thriving future.

Making sure we don’t go hungry or die of thirst..


RSVP now