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.
Retention and engagement are often a key focus for product teams, and the games industry has some great insights into how they think about these 2 concepts to attract and keep their users.
While games have some unique difference to many products, the concepts in this talk are ones any product team can apply in their user journey. Retention is also not a once and done job, so thinking about opportunities to keep your customers engaged along the entire lifecycle of using your products will also be something discussed in this talk.
Our speaker: Sebastian Pattom – Director at Product at Electronic Arts (EA) will share his experiences and knowledge of his work in the retention space.
Our hosts: Canva is a global online visual communications platform designed to empower the world to design. We create beautiful designs from presentations to infographics, videos, t-shirts and social media graphics.
We recently launched the Canva Visual Worksuite – a suite of new workplace products and features built to empower anyone to communicate visually, on any device, from anywhere in the world.
We believe that our responsibility goes far beyond business as usual, and that what’s good for business can be good for the world: This is part of our two-step plan. We truly believe that good for humanity is good for business, and times are really changing around people’s expectations of what they expect from businesses. We’ve come a long way, though we believe we’re still only 1% of the way there.
You have decided you want to be a product manager and gotten that first job – or maybe you’re in your second PM role. Is it all you thought it would be?? What really have you gotten yourself into as a new product manager?!?
And this session is not just for folks who are new to product management! Folks who have been there … we need your wise words of wisdom and you’ll learn something new too!
This month, we’ve gathered a panel of new product folk (3 years or less) to share their stories of what their grappling with at the start of this career journey. We’ll be taking questions from the audience and guiding the discussion as we tap into this moment in time, that you never get back 🙂
There will be audience participation!!!
We’ll be running an interactive component to connect our more experienced PMs with the newbies in the room and facilitate some speed mentoring rounds between those starting out in their career and those with sage learnings to share.
Jane Card is a career shifter into product after fifteen years helping organisations define problems, generate solutions, adopt new business models and ways of working. Naturally curious and a people geek, Jane is passionate about leveraging different perspectives to make the world a better place.
Heike Radlanski started her career in digital marketing before moving into a product owner role and subsequently into product management. Passionate about understanding people’s needs and pain points, Heike enjoys the process of working in cross-functional teams to create and improve products that add value for those using them.
Hugh Osbourne moved to Product Management after working in design, product design, copywriting and small business jack-of-some-trades. He’s been in successful and failing startups (sometimes in the same week), assembling a impressive toolbox of hacks, workarounds and bad habits. Working now in a growing organisation, he’s interested in the secret sauce of small teams, why data products are the best products, and how to domesticate ‘wild’ PMs
MYOB has been part of the fabric of doing business in Australia and New Zealand for more than 30 years, having grown from its status as the original Australian unicorn to now employing people across Australia and New Zealand, based out of nine locations in the region. Having started life as accounting software, MYOB has undertaken significant steps toward becoming a cloud-based business management platform that brings together key workflows to fit a business’s needs.
To see what it is like to be an MYOBelievers, check out our careers site.
After working in product for a number of years, and building up your knowledge and experience, what’s the next step? Is it time to move into product leadership? And what does that even look like?
In April, it was great to be joined by Chris Holmes (VP of Product at IntelligenceBank) to share some of his experiences and perspectives, with lots of familiar (and new) faces in person, and with just as many online, including a couple of special visitors reaching us from as far as Germany and London!
Generally the first step to leadership is taking on a senior role. This can mean different things in different organisations. From looking after more critical products or projects, with more attention from stakeholders, to possibly having some people under you to manage, such as associate product managers, product managers or business analysts.
Head of Product / Product Director / Vice President of Product
What are the differences in all these titles? There is some localisation, with Head ofs being more popular in Australia, and Vice Presidents being more prevalent in the US. Regardless, as you progress to this level, you’ll typically be managing a team of product managers, and be more responsible for the strategy and its execution. The scale continues to get bigger.
Chief Product Officer
As you move up, the scope (and scale) continues to change, with more complex products or multiple products. You become completely responsible for end to end growth of the product, covering acquisition, retention, revenue, etc – the full range of AARRR metrics!
Common Myths about moving into Product Leadership
You can use the skills that you use today
Moving into product leadership requires a new set of skills to scale whatever success you may have experienced as an individual contributor. Coaching, developing and letting go of some of the product processes, and allowing your team to occasionally stumble and to find their own way.
You get to make all the calls
Although you may be able to use your seniority to veto decisions and make your own calls, you should proceed with caution. Much of product management is about aligning your stakeholders and to ensure everybody is pulling in the same direction. In the long run, you want to empower your team to be able to make those good decisions.
Product leadership is the next step in your product career
If you enjoy solving product problems, testing different hypotheses, and talking to customers, there is nothing wrong with continuing to be a product manager. You don’t have to move into a leadership position. Is it really something you want to do? The question you need to ask yourself is:
Do you want to manage people, or manage products?
An Average Day in the life of a Product Leader
Communicating with stakeholders
Much of Chris’ time is spent connecting and listening to various stakeholders. From aligning with the leadership team, to hearing from other team members about what’s happening in the market, and managing any escalations and issues that come up. It is extremely important to make sure everybody is on board with the strategy. Ultimately, creating relationships with other areas so you can tackle problems together.
Managing expectations
Part of being a product manager is saying no to people and their ideas. Make sure you get a load of practice, because as you move up, this only continues. Except, now it will commonly be to Head of Departments or even the CEO.
Strategy
Whether you’re setting the strategy, evolving the existing strategy or changing the direction of the strategy, you will need to constantly work with your colleagues to ensure you have alignment. For established products, you’ll need to understand where your product sits, and how you want to approach things.
Coaching and development
Make sure you allocate time to spend time with your team. Time to hear feedback from people they’ve worked with, or others in the team. How they’ve tackled problems. To give some insight, Chris usually spends about 50% of his time coaching his team, from going through the General Assembly content that he used to teach, and now with fortnightly dedicated product time.
If you need to build up a team, get ready to spend plenty of time in recruitment.
Dealing with something on fire
Like any company, there will be issues that arise. However, as a product leader, your role will evolve from putting them out yourself, to dealing with your team, so that they can resolve things themselves.
This might all seem like the regular stuff for any product manager, however as you become more senior, it becomes more about scale, having a broader viewpoint, and how you deal with things, whether that is shifting resources, changing scope, or helping to get decisions made. Remember to keep a cool head, and act like a leader.
The Essentials of Product Leadership
Being a product advocate
There will always be elements and nuance between different products and industries, and things will never always be set up perfectly. However, the key should be about setting your team and yourself up to be empowered to make the right decisions, and to deliver the most value for customers at scale.
As a product leader, you will have a seat at the table with marketing, sales, customer success and other teams, who will be pushing for certain things, which gives you the opportunity to bring the end-user to the forefront, and advocate for them.
Establishing processes for your team to validate things at different stages of the product development lifecycle, from opportunities and discovery, etc. And then giving them the space to actually do it, and not just moving through an existing roadmap of features that have been prioritised from above.
Communication
Like all product roles, communication is key.
Identifying your stakeholders, and understanding who will need high frequency-high touch, and who will need low frequency-low touch, and working with them to get on the bus.
Also another great opportunity to empower your team to connect with other stakeholders (including senior ones), allowing them to gain visibility, and set them on the path to success.
Lastly, make time for your team, so you can see how they’re going, where they are struggling and what support they may need.
Know your Market
Recognise where your product sits and who is your addressable market? If you need to move into another market, what does that look like? What are the similarities where you can leverage existing solutions? What are the differences where new strategies will need to be developed?
Understanding your team
What are your team’s strengths and weaknesses? What motivates them? Be sure to carve out time so that you can understand them. Where can you leverage their strengths? Where do they need more development and guidance? A good chance to match their responsibilities and goals back to their KPIs.
Moments of Truth
Define what success looks like
It’s essential that you know how your product is performing, as you will be the one reporting back on how successful your product is.
Make sure your team knows what success looks like. Set it up together with them, so that when decisions are made, it can be linked back to success.
Sometimes, with established products, there may be an abundance of data available. However, if they are not driving any decisions, you may need to go back to basics:
Define the core feature and actions.
Do some historical analysis and overlay them with metrics such as Customer Success, CSAT, NPS, etc.
Baseline – if you don’t know where you are today, how can you measure any change?
Culture
It is not uncommon to find companies that are stuck in the build trap – who only focus on delivery and not much else. These companies with a poor product-practice can be difficult to change. They may be supportive at first, but it takes time, and constant reinforcement to show the value of product thinking.
Talk to some customers. Showcase the findings. Bring people into the process, and get them hooked on the insights.
If you’re going to move something into development for a few months, and spend so much time and effort, it really is worth taking some time to sort out the basics first, validating customer desire, and that the solutions will make a difference.
Setting Up your Team (and yourself) for Success
Set clear goal and objectives;
Process and systems;
Make time for coaching and development;
Prioritise ruthlessly; and
Get out of the way.
Lessons Learnt
Delivery can be one of the hardest items to control when moving into product leadership.
Use your influence to change the direction of the product.
As you scale, there is usually a (false) expectation to deliver faster.
When faced with time pressures to deliver, you can consider changing resourcing, or scope.
Consider how you will disseminate information to stakeholders. Create different rituals to bring people into the tent, and involve your team to help spread the load. This will also help remove yourself as a bottleneck for information and future updates.
Spend time with customers.
Just because you move into a product leadership position, doesn’t mean you should stop hearing from your customers directly.
Reserve time to listen to your customers, so you can understand how they are using the product. What do you really like about the product? What are the gaps?
Bring a Product Manager, so you are not listening to feedback in isolation.
Empower your team
Create a safe space (with appropriate guardrails) for your team to try things and learn.
Have regular check-ins, so you can hear feedback from them, or their stakeholders.
Get them to present to others and senior leaders, so they can craft their style, and also build their credibility.
Don’t try to change everything at once (or by yourself).
Just like a product, there are an endless number of things you can do or change.
Develop a strategy and be realistic of what you can achieve.
Where are you now, where do you want to get to, and what are the steps to take to get there?
Don’t just start trying to fix everything, and burn yourself out.
Get help!
It can be overwhelming when you are new to the role, with large amounts of information to learn, and stakeholders approaching from all directions.
Network with other product people and leaders, and see how they approach things.
Get a product mentor for advice.
Planning the Move into a Leadership Role
Look for opportunities for growth in your current role.
Act like a leader.
Be comfortable with uncertainty.
About our Speaker
Chris Holmes is a digital delivery and product specialist with over 10 years experience launching and managing products for companies including Jetstar, SWEAT and Origin Energy. Chris has a strong passion for customer experience and driving change through technology, and central to his product management philosophy is a focus on ensuring collaboration to deliver results.
Chris is now VP of Product at IntelligenceBank, a marketing operations SaaS platform that delivers applications for management of digital assets, creative approvals and compliance, marketing project management and creative distribution.
For our March session of Product Anonymous, we were fortunate to be joined by Amir Ansari, Global Head of Product Design at Iress, to share some of his experiences with raising design maturity and capability in his organisations, and it may not be how you would initially think.
Appreciation of Product Design
Over recent years, many more companies have started to appreciate the value of product and design. And as an industry, we’ve seen a bit of an explosion in growth. Many companies have bolstered their design teams, and transformed the way they work.
Atlassian grew 1600% or 16x in 4 years (6 to 106 designers)
Coles grew 550% or 5.5x in 1 year (10 to 65 designers)
But how many designers are enough?
Is it even about the number of designers? Or more about the ratio of designers to developers?
So what’s the best path for designing and building better products? Is it to hire a bunch more designers, and get the ratio down? Some implications of this approach may be your increase in overhead, and the need to change your operating model, which is not necessarily a terrible thing. However, surely there’s a more scalable way to grow.
In fact, according to a Nielsen Norman Group article, the typical ratio alone does not ensure greater organisational impact, better designs, or more usable products.
The Challenge – How might we Improve Design Maturity…
When we talk about Design Maturity, we’re talking about:
Product Design
Innovation
Human Centred Design
User Experience
UI design
Visual Design
Service Design
Back to that designer to developer ratio. For Iress, the ratio is 1:35. Or 1 designer working across 5 squads. That’s 14 design practitioners, grown over 20 years, covering 120 products. When it comes to design, Iress still falls short of a minimum acceptable amount of practitioners.
An assessment against NNgroup’s stages of UX maturity would be between 1 and 2, with obvious aspiration to move towards a 6.
So therein lies the challenge – how might we improve the design maturity, without unrealistically increasing UX headcount.
Guiding Principles
As the old adage goes, If you give somebody a fish, you feed them for a day. But if you teach somebody to fish, you feed them for a lifetime.
The same goes for design – to increase design maturity, don’t just rush to increase design headcount.
Over the past 15 years, one of Amir’s fundamental principles has been to democratise the craft of design – to teach and empower everybody within the organisation to practise design, from customer research, to experimentation, validation and much more.
Ensure everybody has the confidence and is empowered to talk about design. Talk about the product. Talk about the customer. Talk about the end user.
Designers are facilitators of the design process. Not owners of the design.
Everybody else in the room, from Business Analysts, Quality Assurance, Engineers, Product Owner and Product Managers all have a perspective and opinions too. Use the right toolkits to validate those opinions.
“Do the best you can until you know better. Then, when you know better, do better.”
Maya Angelou – American Philosopher
Nobody can be an expert straight away. Mastery comes with practice. So continue to practise and build that muscle.
Don’t start by putting slide decks together to pitch for why design should be more valued, or why you hire more designers. Rather, get out there with the clients, and start doing design work, and showing value. Use that newly created value as the enticement to invest more in design.
Strategies
Educate, coach, train anyone who shows interest, and promote DIY.
When Amir first started at Iress, there were only 6 designers to support 700 engineers. Way too many to try to teach every single engineer about design practices. So one of the first things they did was to document their playbook, starting with some of their most common human-centred design activities that were relevant to Iress. And without jargon, so that non-designers could understand and follow too.
A typical Playbook Topic skeleton could include:
What is it?
Why should you do it?
When should you do it?
How to do it?
Resources and templates
Skill level required
Typical duration
This way Business Analysts, Product Managers and others could read the content, reach out for guidance, and give the activity a go.
Following the activity, the design team would debrief them – how did it go? What worked, what didn’t? Try this next time. Essentially, helping team members add another tool to their toolkit.
The design team also tracks the playbook engagement. Who is visiting, and from which disciplines? Which topics are being used? Are some topics being neglected? Do they need to run campaigns or refreshers to get people to re-engage?
Create champions
It’s important to reduce the friction for non-designers to get involved, learn and talk about the design craft. At Iress, they introduced communities, and have created over 25 design-specific slack channels, some around design-related themes (eg, the Iress Design System), others based on region (eg, for Melbourne Product Design Team, or the UX Research Enthusiasts UK channels).
Also, after running design activities, Amir’s team gathers feedback and measures the sentiment of non-designer participants about the process. Was it valuable? Could something be done better? Would you come again? Build interest and iterate the process so that people want to return.
Bake into existing processes
When you’re trying to change the way people work, there is always going to be resistance. Everybody is already overworked. Reduce the barriers. Break up the processes and the craft, and insert smaller portions into existing processes.
Product design principles – agreed and followed
The Design Team (or one of their principals) created a design charter, or a set of principles, that the team could easily and quickly refer to, so regardless of where they were in the design or build cycle, they could check that they were on track. Have they removed their biases? Did they understand what success would look like? And can it be measured?
Make it a team sport
Design is a team sport. We all work for product companies. We are all responsible for delivering value to the customer through the products we build.
Create demand in product design and UX.
Show value from the UX craft, so that more people want to join in and share the same
Beware, some of the Traps
The Dunning Kruger Effect
After you’ve coached somebody, and they’ve read a bit of material from your playbook, and even run an activity, there’s a danger that they overestimate their ability. There is a chance that they start to erode the craft of design.
Constant education and reinforcement is required.
Did you know you only need 5 users for meaningful research? But did you also know you should have asked the user this, and you should do that.
Did you know if you run a design sprint, you need to prepare x, y and z?
If you build it they will come
You cannot assume that just because you’ve taught a group of people once, that they will continue. Everybody has their own work to do, and their own agendas. Again, constant education and reinforcement.
Thank you
Thank you so much to Amir for sharing his insights; our volunteers – Gwen, Nosh, Sakthee and Steve; and our event host – SEEK.
Further reading and resources
Some resources mentioned during the session include:
