Do you have a dedicated Product Marketing Manager or an entire team standing by to help bring products to market? Or is marketing yet another hat you need to wear on top of all your other responsibilities?
Join us to discover strategies and techniques on how to work effectively with marketing, leverage your own capabilities or bring the right expertise on to give your product the best chance for success.
Our Speaker: Vanessa Sammut is a Marketing Strategist at AlwaysOnMarketing, helping purpose driven businesses connect with customers in a meaningful way so they can grow brand awareness and reach their ambitions. Vanessa has a background in developing and executing B2B Strategies for a range of technology-based businesses. She has built marketing functions from the ground up, growing teams, developing value propositions and working with Product and Sales to executing Go-to-Market.
Our Host: me&u! When it comes to food experience, me&u helps you always feel like a local. The company’s vision is to bring that feeling to everyone, anywhere – so no matter what neighbourhood you live in or visit, you’ll always know the perfect place to go and exactly what to order. me&u is used by 6000+ bars, pubs, and restaurants to create memorable guest experiences and grow their brands. With 200 staff in five countries, and headquartered in Melbourne, Australia, me&u is the consolidation of two leading hospitality technology companies: Mr Yum and me&u, who merged in November 2023.
Product Discovery is an essential part of Product Management and yet, the art of doing it well still remains elusive.
Enter Melissa Klemke, Head of Product at Prezzee, who taught us how to win the Product Discovery game – with a little Bingo! (Slides at the end of this post)
Why do Discovery?
Have you ever worked with an organisation that allocated resources and spent months or years building something big that nobody ended up wanting?
Have you ever caught yourself thinking that because you’ve known the user base for years, surely, you know exactly what to build!
Or have you built something only to realise someone else has already built it and even better?
Hence, the purpose of Discovery is to reduce the risk of failure and uncertainty.
In Product Management, there are 4 primary types of risks
Value Risk: will customers buy it? Will they use it?
Viability Risk: can it work as part of our business model?
Usability Risk: can the users figure out how to use it?
Feasibility Risk: can the team build it with the time, skills and tools available?
While discovery should involve all members of the product trio, Product Managers are primarily focused on addressing Value and Viability Risks whereas Designers focus Usability Risks and Engineering on Feasibility Risks.
In Melissa’s talk, she focused on what the Product Manager can do to reduce Value and Viability risk.
Common Mistake(s) in Discovery
Mistake #1 in discovery is assuming everything will work out perfectly. The customer will love it (value), they’ll know how to use it (usability), and they’ll pay a lot of money for it (viability). Until they don’t. Strong assumptions lead to high risk. But how do some companies end up in that position?
In some cases, time constraints can lead to assumptions being made. It can be tempting to substitute customer research with internal subject matter experts (SMEs) who represent ‘the voice of the customer’. Perhaps an hour of making product decisions with a SME can save an organisation a couple of weeks of discovery – but in the grand scheme of things, saving 2 weeks of time in discovery may not be worth it, if you end up spending months of time and moneybuilding a feature nobody wants.
The thing is, every user is different. An SME is a single person and it’s challenging for this single point of view to accurately represent the nuances and needs of multiple personas. Even more so when the needs are of an organisation with multiple personas and processes to support. Moreover, an SME is a power user and may overlook counter-intuitive experiences for the regular user.
Where to start? Talk to customers!
A quick and easy way to address Value Risk is running customer interviews.
Imagine this, a work desk with you the interviewer, the interviewee and a couple of your teammates who are observing and taking notes. You’re recording the session and you’ve asked for permission.
Talking to Customers: The Script
Before you actually talk to the customers, you need to prepare your script and have clear goals Document your own internal objective of assumptions/hypotheses that you’re trying to prove or disprove along with what behaviours you’re trying to learn more about. This is your anchor throughout the interview.
When you talk to the customer, set clear expectation with the customer “We’re here to learn about how you carry out X,Y, Z process. Your insights will help us shape our decisions for A, B, C”. You are not there to take feature requests.
Have 5-7 questions that will be asked of each customer so that it’s easy to identify patterns of similarities and differences. It’s difficult to get good insights if you’re just winging it and asking different questions each time!
Talking to Customers: Behind The Scenes
Everyone knows it’s hard to take notes while talking. Melissa recommends setting up a digital whiteboard for the team to take notes.
In a shared document, have team members contribute notes. There may repetitive notes or different notes – you can address that later. Just get it down on paper or docs or post-its (virtual or other).
Melissa shared “nothing gives me more pleasure than hearing two engineers argue about what they heard the customer say. Involving them makes them more customer-centric.” It also makes it easier for the team to discuss customer impact and trade-offs for the solution later.
Separately, create a separate space for the team to draft and ask questions that pop up during the interview.
Talking to Customers: Recruiting
It takes a village! Treat it like a program that needs to be managed. Give it a cool name (When Melissa worked at ELMO, they called it ELMO Loop to ‘close the loop’), sort out messaging (“shape our next big thing!) and Expressions of Interest forms.
Leverage your wider customer-facing team members (Customer Success, Account Managers, Implementation, Sales) to roll out the red carpet for your “customer advisory board”.
You can also do – Competitor Teardowns
During the Bingo activity that Melissa ran, competitor teardowns received the most interest from the audience as something new they’d try. It’s useful for assessing Value and Feasibility Risk.
Rope in your sales, marketing & product team members
On a digital whiteboard, break down the user journey. Go page by page and spend 5 minutes talking about each page.
Talk about – likes and dislikes, the clarity of the messaging, what their price structure is (free? subscription? how much $$)
Assess the patterns – what are the similarities & differences between competitors
Decide if you will ignore, copy or make it better than your competitors
Thank you to our hosts – Propel Ventures!
At Propel, we’re dedicated to helping businesses achieve sustained product success. That means not only bringing your product ideas to life, but also ensuring that they remain relevant and successful over time. With our unique blend of software development and product strategy services, we offer a comprehensive approach that goes beyond just delivering a product. Our goal is to help you create long-lasting results that drive growth and success for your business.
Founded in 2016, we are a team of entrepreneurial product strategy, design and development leaders with a track record of building businesses, creating and expanding markets, and developing new technologies that benefit millions of people across the globe. https://www.propelventures.com.au/
This month we ran a workshop instead of a talk. If you attended, we’d love to get feedback on this session. Would you like more of this? What worked well? What could have been better? Reach out to Jen & Liz on the ProdAnon slack.
Designing the box+
The ‘Design the Box’ is a classic activity created by Gamestorming.com in 2011. The goal is simple – to create the design of a physical box that sells your product. The limited real-estate and creating a physical ‘thing’ forces participants to focus on who is the customer, what is important for them, and how do we influence the buying decision.
This is known as the value proposition – simple statements that summarizes why a customer would choose your product or service. Every value proposition should speak to a customer’s challenge and make the case for your company as the problem-solver.
Essentially this activity is about identifying the ideal customer persona (ICP) for your product, and the value proposition that will engage your customer to buy your product.
How will your box grab the attention vs all the competitor boxes?
Steve Bauer took this classic and fun activity and rebooted it for the online world. The product isn’t always a box any more. It could be an information card hanging at Officeworks, or a Gift card at 7-11. Alternatively it might be an electronic representation instead of a physical product; like a web landing page or an App Store page. The sales channel may change, but the customer still needs the product. Identifying and designing the channel for the ICP and value proposition and designing for the channel still needs to be done.
Definitely try this at home.
This is a fun exercise you can run at your own company. For example each team competes for the design of the same product, the teams takes separate modules of the product, or the team creates competitor products. The activity, the focus on the customer, and the learning about your value proposition is the same.
The steps we followed were:
Create groups. A good size for collaboration is 4 or so people
Fill the box. Choose the product that is inside the box; physical or virtual.
Choose the shape. Is it a physical box, a landing page, a gift card, etc.
Build the box. Create a physical design
Share the box. Share your design with other teams, highlighting why certain value propositions were considered important.
Ready, Set, Go…
Once teams formed, they needed to decide on a product so there was a bit of brainstorming! It turns out people are too happy to chat about ideas, or what goes on the outside. However quick reminders about the time helped nudged them into making decisions and moving on.
Overall we had some fantastic products and boxes. We ended up with 3 products focused on pets, a few concerned about the environment and one protecting us from scams (all details below).
Team 1: A self driving car for teenage drivers.
Specifically the buyer is the worried parent and the user is the teenager (who can do their homework while on the way to school because they’re not driving!). For the parent, the benefits were safety and control. Lots of data and logos of safety organisations to communicate this self driving car is safe for your teenager who has no or not so great driving skills. Teenagers make mistakes, our cars don’t!
Teenagers & Cars. OH MY!
Team 2: ChatGPT premium gift cards
Expanding on the current ChatGPT product, one group re-imagined what it looks like as a physical product. Creating a gift card similar to the Spotify, Amazon, JB HiFi cards you see for sale at various stores, they offered a 3 month subscription. This helps to bring awareness to ChatGPT to a much larger audience including those non-techies. They did they by showing sample questions to the packaging to help show what people can do with this and how it might appeal to everyone.
Team: ChatGPT as a subscription
Team 3 – Hear Boy
This team created a product for dogs with hearing loss (which impacts 20-30% of all dogs) to help them hear the world again. It reduces anxiety by 8%, increases walkies by 250%, simple and easy to setup, recommended by vets, lifetime guarantee! The slides of the box highlight partnerships which let your dog have an even better life – dog playlists to listen to and an ai costume generator! *note: Product Anonymous does not vouch for any of this data 🙂
Solving dog hearing loss!
Team 3: BuddyBot for housework and pets
The next team tackled 2 problems we’re having now as we return to the office – the anxiety we have about leaving our pets at home alone and not being able to do housework between meetings. With BuddyBot, they have brought together a robot vacuum with AI to play with your pet which let’s you watch the play via their app! Their design had big pet pictures on the front of the box to draw you in and lots of features across the back including warranty information and highlighting the vacuum has won the 2024 Good Design Awards!
Clean the house & reduce your pet’s alone at home anxiety at the same time! Winning at adulting!
Team 4: Taste good, do good, feel good coffee
Sustainability & traceability of coffee was very important for this team. On the front of the box, they focused on a simple message of the quality of the product (which is good!) and that you are doing good by buying the product. They included the the logos of various environmental groups to give it the thumbs up that this is a legit product. On the back there was information on how it was sourced ethically – even the the box itself is sustainable because you can return/exchange it.
Designing the perfect coffee
Team 5: Saving the planet with recycling
Our next group had a product where you put your e-waste in the box and it spits out new electronic products. On the front of the box, there’s lots of social proof including that it’s been #1 seller on Amazon, approval from your local council and a quote from an environmental organisation CEO. Their tag line: Save Money! Save Time! Save Space! Save the Planet! Use that box of cables you have at home! On the sides, there’s the colour options and visual design (not text) instructions of how you take that box of cables you have at home and recycle with this box! Of course the the bottom of the box was reserved for ‘lots of legal stuff’.
Saving the planet by helping us recycle those old cables
Team 6: Dogminder
There’s also the dogminder product – version 2 now comes with more pats! This is a service represented in a box so there’s lots of cute pix of dogs! There’s lots of quotes from users including dog users (‘woof!’). Having easy steps to follow to use the service was also important.
99.9% of our dogs recommend us to their other dog friends
Team 7: Crook Block
This amazing product blocks your phone from receiving spam calls and messages. On the front of the box were the logos – certified by AFP & AU Govt and lots of seals of protection! plus ‘Now with more AI’ They used a humorous approach including an image of a phone with a chastity belt on the back of the box.
Team 8: Protein jelly shots
This team was helping the hard gainers who power lift, but don’t see massive improvement in strength because they struggle to get enough protein. They developed high protein jelly shots to help you! The front of the box was full of numbers and benefits – each shot has 50 grams of protein so you only need 2 a day to reach what you need, low sugar, vegan, gluten free, low gi, all the free things, stevia AND available in 5 flavours! On the side of the box you can scan the QR code which brings you into the community and gives you a free sample.
And the winner is…
All of the groups did such a fantastic job with their boxes, we decided to have everyone present and have our hosts, Chargefox, select a winner!
Nick about to announce the winner. Our winning team! Baani, Dileesh, Jun & Yau with protein jelly shots!
Thank you to Chargefox for hosting!!
Chargefox is part of the AMS Group. Every day thousands of drivers charge their vehicle on the Chargefox network – the largest and fastest growing EV charging network in Australia. We’re owned and operated by the NRMA, RACV, RACQ, RAA, RAC and RACT. The same companies supporting drivers for over 100 years. https://www.chargefox.com/
Want to run your own Design the Box session? Reach out to Steve and the Product Anonymous team. Alternatively jump to gamestorming for more details.
Discovery is incredibly important though there’s a lot of ways to do discovery – so what’s the right way to do this? Or do you really need to do discovery?
Our speaker, Melissa Klemke, Head of Product at Prezzee, will take you though an interactive session and will be covering a lot including:
Types of research
Working with User Researchers (if you have them & what if you don’t)
Setting up a research program and customer pool
What market research is useful and how to do it
Forming hypotheses
Experimenting
Tooling (with and w/o fancy tools)
Solutioning & technical discovery
Our Hosts:
At Propel, we’re dedicated to helping businesses achieve sustained product success. That means not only bringing your product ideas to life, but also ensuring that they remain relevant and successful over time. With our unique blend of software development and product strategy services, we offer a comprehensive approach that goes beyond just delivering a product. Our goal is to help you create long-lasting results that drive growth and success for your business.
Founded in 2016, we are a team of entrepreneurial product strategy, design and development leaders with a track record of building businesses, creating and expanding markets, and developing new technologies that benefit millions of people across the globe. https://www.propelventures.com.au/
Or maybe the question is – do you think about your value prop? How do you communicate your value prop?
This month we’ll organise you into small groups to do a bit of a workshop. We’ll have an exercise that might mean you need to bring your own paper and scissors to help you think about your products value proposition. Jen + Liz + Steve B will be your fabulous fun hosts.
NOTE: We have some stationary from Product Camp but if you have your own sharpie to bring, that would be helpful! Sharpie colours are good!
Chargefox is part of the AMS Group. Every day thousands of drivers charge their vehicle on the Chargefox network – the largest and fastest growing EV charging network in Australia. We’re owned and operated by the NRMA, RACV, RACQ, RAA, RAC and RACT. The same companies supporting drivers for over 100 years.
Upgrade your product delivery with OKRs (Workshop)
One of the best things we can do as Product people is get our teams excited about solving real customer problems and measuring success. We’re going to cover just that in this session, we’ll explore how to go from strategy and discovery, to validating the impact once launched with the Objective and Key Results (OKR) framework. A goal setting framework used by some of the world’s leading product businesses, like Google, LinkedIn and SEEK. This will be a practical session, so be ready to work on your product!
Our Speaker:
Tim Newbold, OKR Coach and founder of OKR Quickstart will be our speaker. Tim founded OKR Quickstart to help tech companies unlock growth. They do this by creating focus on the biggest growth constraint, getting the team behind the plan to solve it and delivering meaningful results. He has a background leading product engineering teams in SaaS and Fintech businesses. Tim loves to work with some of the worlds leading tech businesses, such as ELMO Software, Domino’s, SEEK, Carsales & Connective.
Our Host:
David Jones As one of Australia’s most iconic retailers we have a rich 185-year history of being a curator of world-class brands. Our people are driven by the passion and desire to inspire our customers with seamless service and experiences like no other.
Kate Lanyon came to speak to us about the relationship between product folk and engineers and some of the areas that can create friction between us. She’s got some great tips and insights as to how to reduce this friction and help create working relationships that kick ass! Kate’s been an engineer for a long time and draws on her experiences of being that individual contributor and performing some of these sins herself – through to being a CTO and co-founder where she’s also led engineers and had to coach them in some of these areas.
Her most recent experience at a startup digs deep on this topic because if engineering and product aren’t in sync in this environment, then you’re not going to be successful. Start up land is a fight for survival. If you haven’t worked in a startup, startup is like the most extreme form of product development that you can have. A startup must find value, before the money runs out, and raise more money than exponentially find more value to raise exponentially more money. Even if your team is not fighting for survival, hopefully some of these tips will make your life easier.
Lastly, an important disclaimer to every story or generalization shared in this talk, it doesn’t do justice to the uniqueness of every individual. So do take these examples as an opportunity to be curious and ask more questions of those you work with.
So what do engineers do?
Kate’s definition of what engineers do every day is that they apply deep knowledge to solve complex problems. It takes a lot of learning to be a great engineer, learning from each other, learning at conferences, and they learn different things, programming languages, techniques, they have to learn the system that they’re working on. There is a whole lot of learning and deep knowledge that goes into being an engineer.
The day job involves a lot of complex problems to solve. And even though an engineer may have done a thing before, a lot of web development is just forms and websites and things right? Yet, every system is different and every system is constantly changing. Even a thing done yesterday, trying to do that thing again today, it’s gonna be slightly different. Things move so quickly, the world around us changes really quickly, and engineers have to keep up with it. Working in code, there is never one single way to do things, there’s many ways to do things. And a task is broken up into many layers with many decisions. So engineers are constantly making decisions.
“It’s not as simple as just like, hey, build this thing.”
It’s not a straight path forward – sometimes an engineer will get stuck. Several constraints will come together in a way that it’s not easy to see a way forward. This is when an engineer will go play a video game, go for a walk, or leave for the day and go to sleep and wake up at 2am with a huge burst of creativity and a way to solve the problem. As Kate shares from her own experience this can happen regularly, where the moment of distraction is the moment you come up with the solution.
Her other insight is that there’s something Pavlovian about coding. It’s having a plan of how something should work, writing that down, and then running it and seeing it work, or not work. And doing that multiple times an hour, the joy at the code running, in the test passing or the frustration when it doesn’t. That’s micro level but it’s constant in an engineer’s day. And it’s just again and again and again. Perhaps that description makes it sound bad, but it isn’t, it’s not bad. It just is what it is. Yet that’s important to explain to product folk who sometimes don’t understand that internal world of an engineer and that lived experience.
To summarise, engineers are always learning and researching. They’re always understanding the landscape and the system that they’re working in, and the constraints that they have to work with. They’re constantly making decisions and evaluating what they’re doing and the way forward. They have large leaps of creativity at times. And a continual evaluation of success. These are really useful skills in other things as well. These are the things that engineers are training their brains to do every day.
How to engage your engineers
To quote Marty Cagan “if you’re just using your engineers to code, you’re only getting half their value”. Why does he say that? Because the engineers are closest to the technology, closest to the breakthroughs and what is just now possible, thus they’re a great source of innovation. Kate adds to this definition that the skills learned today through coding, when put towards solving customer problems, as opposed to focusing just on delivering what they’re asked, then engineers can be a great contributor to finding the fastest path to value.
So how does this work? Marty lays out several ingredients to having an empowered engineering team. You need a product vision that is intended to attract and inspire these engineers and you need a product strategy to ensure that engineers are working on the most important problems. You also need team objectives to give the engineers a clear statement of the problem to solve and the outcomes to strive for. None of this should be new to a PM (product manager) but it’s certainly reassuring to hear from Kate that these tools are truly useful for all members of the team.
In addition, the PM and the product designer on the team provide the engineers with critical constraints regarding the business viability and the customer experience. User research and data science provide the engineers with key insights to factor into the problem solving. Then as a team, you can find a really effective path to value. In terms of working in your own teams, take a look at these ingredients and see if you can understand why the engineers on your team joined the company that you work for, why your team exists, and how your team measures success, you can start to have really good conversations with your engineers at a higher level than just what can or can’t be done. Instead you’re discussing how we can solve the customer problem.
As an example (see image above) here is everything that we can make in the system, right now, things are coming in and out of this circle all the time. The engineering team, ideally, is aware of those. Then there are the things that solve the most important customer problem, this is where the product team can frame this for the engineers. Now we’re working with two constraints. Then there are the things that the engineers know the customer can actually use, the product designer gives us these constraints. In addition to these myriad of inputs are also budget, deadlines etc. Ideally, together, we find the jam of the thing that we should be doing next. And at this moment empower your team of problem solvers to solve customer problems. Like what could go wrong with this right? Nothing could go wrong!!
Technical perfection
Now we might get to technical perfection – this is something to be aware of. It’s hard to see. Because it can look like things taking longer than you expect. There can be other reasons for that. But it’s important to be aware of why engineers gold plate things, or over engineer them. We are incentivized by our industry to do this. This will happen when your engineering team is more excited about solving the problem in a technical way, they’re more excited about the solution, rather than solving the customer problem.
This is a natural consequence of just being told what to do. “Build this thing”. This shifts the problem to how to write the code. As Kate has said, she’s felt this too, and has gotten excited and made that into a challenge for herself. However, the engineering industry also wants engineers to do this.They’’re rewarded and recognized by their peers, and the industry, if they do stuff that’s hard and challenging and interesting and new. It demonstrates mastery, if they make something that’s technically perfect, even if it doesn’t solve the customer problem. In Kate’s words – I can write a blog post about a thing that’s completely irrelevant, but it’s cool, technically. I’m having a bunch of people telling me how awesome I am.
How good an engineer is, technically, is how career progression is assessed. If one was to write something really simple that solves a really big customer problem, will a manager be impressed by that? Sometimes if they’re a good manager, but a lot of the time No. And since engineers just love learning, the new and the technically difficult is something that they’re just naturally attracted to. Editor note:This insight into how a product person can actually “trigger” this behavior when potentially the attempt to keep things simple by sharing less information to avoid this situation was an Aha moment!
Feedback cycle
To quote Brian Cantryll – he’s a CTO & co-founder at oxidecomputer – “Above all else, engineers wish to make useful things”. All the engineers where Kate works love this guy. Brian cares about the customer. He wants to build useful things. Thus, an engineer’s highest priority is to satisfy the customer through early and continuous delivery of valuable software. This is the first of the twelve Agile principles, ironically enough, written by a group of engineers! Engineers are capable of caring about the customer problem, but they have to be included in that conversation.
At this point though it’s worth talking about why that conversation might not be happening. One of the things that can go wrong in those discussions is whether or not the feedback or questions are perceived as criticism or analysis. Engineers are direct at times. Those skills that were mentioned earlier that engineers develop, the dark side of that is that they have an overdeveloped sense of critical thinking. That is not something that can easily be turned off, that Pavlovian response means that engineers’ brains are trained to try and find issues early. That’s how they get to that little moment of joy.
That is then reinforced constantly on any working day. An engineer cannot turn off their critical thinking. They can’t not say something, if someone just presents them with a solution. In Kate’s experience, she’s going to immediately see three issues with it. It’s just whether she tells them, and she can’t not do it. It would be like walking around and trying not to read billboards or street signs, the human (engineer) brain just does it. The reason it does it is because of the length of experience doing this job. The call out here from Kate, is not that you should take crap from engineers. Instead, when an engineer comes to you and it seems like negativity, maybe just take a second look and assume good intent. Is it criticism or analysis?
Is it badly phrased? Could they use some feedback about how to better phrase things? It can be very easy to experience the directness of engineers and their ability to find issues and holes and things as a personal attack. It’s not generally meant that way. Some people are assholes but for the most part it’s not meant that way. Thus, when your engineers come to you with problems or questions, you should feel free to work through that. Try asking them questions and engaging in your own curiosity, answer their questions as they’re trying to understand better what’s needed here and try to help them understand what you need from them. However, do work with your engineering leadership to give feedback on how to collaborate better if this is a clunky type of discussion despite your best efforts to engage in discussion, because you’re doing everyone a favor if you also encourage feedback and coaching in this area.
Trade-offs
I want to talk about trade offs – don’t try to actually interpret the picture above – it’s from a textbook. It highlights the system attributes and how they all interact with each other. The reason to show this is because when engineers say no, or they ask questions, this is what is in their head, but exponentially larger. Thus it’s up to you, the product manager, to figure out how deep you want to go into this. What questions do you ask now? Your engineering colleagues will be happy to explain it to you, if you’re willing to listen. It might not be that easy for them to express this in words (Editor note: a replay of some fascinating team chats where I’m sure we were talking cross purposes, because I, the PM, wasn’t actually being curious. And the person across from me was likely struggling to figure out how to explain this massive image in their mind to me!!). Generally, the criticism comes from trying to unpack all of this. There are limitations of the system, the conventions of the system, like the engineering principles of the company. Even something as simple as will this get past code review? Can this be done within the deadline? There’s a whole lot of calculations that are being done, that they’re not easy to articulate because of all of what’s oversimplified in the above image. As Kate begs, please do ask and be patient in the conversation to get to an answer.
Nonetheless there is something to be said for trusting your engineers to work through this thinking for you and leave them to weigh up all the constraints and come back to you with a good solution.
To circle back to the feedback part – suggested reading of the resource Radical Candor – to help with giving feedback. A couple of reflections from Kate, who found it a super useful resource to improve in this area, engineers are generally fine with challenging directly. We all (engineers and product alike) need to spend some more time caring personally to ensure that feedback is well received and given with the best intent! Because the main message from this book is that if you do provide feedback from a place of caring you can say almost anything. If you can establish a relationship with your engineers, where you’ve established that you care personally then you can give feedback. And in return, you as the PM can be open and receptive to feedback as well. Then the relationships and the team can be more productive. But it’s work. It’s definitely work that needs doing.
Flow
The best thing about being an engineer, in Kate’s opinion, is flow. Flow is a mental state, where it’s extreme comfort, extreme concentration, but it’s effortless. And everything falls away when you’re in it. It’s been studied in artists and athletes, But engineers can reach it too. It’s described as the secret to happiness. To get to this, there’s several ingredients, and you, product people, can help your engineers with those, and help them get to this moment, if you recognise their need for this and respect it. That’s how you can make a connection with your colleagues.
The different ingredients include whether or not an engineer has the ability to completely concentrate on a task. Are they in an environment where they have a block of time that they can get into work knowing they’re not going to be interrupted? Do they know what they’re actually trying to do? Do they have a clarity of goals in mind? Then if we go further, is the task an appropriate skill level for them? If it’s too easy, or too hard, they won’t be able to get into this state. They need to feel ownership over the task as well. You can find more in this Ted talk by Mihaly Csikszentmihalyi. This is definitely a way to connect with your engineers, if you can respect their flow time.
Another area to think about is how to help your engineering colleagues get their technical debt under control. Following on from float, technical debt makes it harder to get into flow. Because the system is muddy and terrible to work with. Technical debt as a term is kind of falling out of favor at the moment, to be replaced with other things like code health or things like that.
Kate’s preference is still the term technical debt, because from the perspective of “debt” the metaphor falls down. Technical debt seems like a loan to be repaid, and no one ever repays it. However, if you think of technical debt as a loan with interest, then it works. Technical debt is any code that’s more expensive than it should be, code one has to pay interest on. That interest is getting paid when you get delays from bugs or in not enabling your engineering team to reach flow and be productive. The way to handle technical debt is to spend time paying it down knowing you’ll never pay it off completely.
If not, that leads us to talk about rewrites. Rewrites are a bad place to be!! You do not want to be doing a rewrite. If you’re doing a rewrite your customers are not going to get any value during that time. These projects always take longer than you think. There are companies that have been really damaged by doing a rewrite, while their competitors have been able to keep going. And in some of those cases they’ve lost everything in that gap of time while the competition moves on.
Going back to that technical friction, rewrites are very attractive. It’s a new puzzle. It means an engineer is free from all the bad decisions that were made in the past, when one didn’t know any better. It’s a great way to learn, it’s going to look super impressive on a resume. However, you can avoid getting tempted by managing the tech debt. Thus tech debt needs to be a regular investment of time to pay down the growing interest. Marty Cagan says that product managers should just take 20 to 30% of their time off their roadmap/planning to manage tech debt, in conjunction with an engineering team always having a prioritized list of things they want to do with that time. Through regular maintenance, you can avoid the need for rewrites. You cannot necessarily avoid people asking for one – it’s always going to look intriguing. You, the product team, should be investing in not getting to the point where it’s needed, because having to halt all delivery of customer value is not going to look good for you as a product team!
Summary
What are the things to keep an eye out for as product folk to work so well with your engineers that you kick ass together?
Use your team of problem solvers to solve customer problems. Engineers need discovery and research time, asking them for stuff on the spot is going to result in them saying whatever comes into their mind at the time. If they have research time, then they can actually go away and prove it and improve their answer. Constraints are good so share them all as you’ll get a better solution.
Help engineers find flow. They produce their best work this way.
Have a discussion about technical debt, assigning time to regularly pay it down. Make sure it’s prioritised. Engineers shouldn’t just fix whatever shiny thing is in front of them, they should have a list of the most important things to fix. Avoid needing a complete rewrite!
A really good starting point in finding common ground between Product and Engineering is one of the twelve Agile principles (these were written by engineers after all) – “satisfy the customer”.
You can find other the slides, other good resources and books on Kate’s site.
Thanks again to Kate for all the fabulous insights and thoughtful suggestions for creating great working relationships with your engineering team! Thanks to Kogan for being our wonderful host.
Our speaker: Kate Lanyon, Engineering Manager at Fastmail, co-founder & former CTO of Eugene Labs will shared insights into the above. Kate has a led a varied career – going from full stack development, to mobile app development and back again before moving into senior leadership. She has worked with teams across many different domains including agencies, start ups and corporates. You can fund musings at her website.
Our host: Kogan.com is a pioneer of Australian eCommerce. We are a dynamic and rapidly growing business. Our team believes in using & building technology to improve the online shopping experience for our customers. We are pragmatic, intelligent, fast paced and driven by seeing our software shipped to production daily. The software we build – including www.kogan.com – is used by millions of customers. Check out our pride and joy https://devblog.kogan.com/ to learn more about us and how we deliver amazing products and software!
As software companies scale and the product team grows, the difference between building ‘stuff’ and performing the practice of product management can be massive. It can greatly impact the ability to find product market fit through to the ability to scale with pace and grace.
Our speaker, Nick Wodzinski, has worked at several start-ups and shared his first hand experience of moving the team into the practice of product management while being resource constrained.
Nick’s 3 tips are:
Think about roles, not job titles
Nick shared some previous conversations that helped to shape this guideline including talking to a founder about Marty Cagan’s idea that each team should have a product person and the founder saying they can only afford him – the one product person. Or having to do some UI and design work although he’s the product person and wondering if he really should be doing this (although there’s no designer at the company).
In order to solve this, think about the role, not the job title. Get comfortable, especially in startups, that someone who might not have the training is going to be doing a specific role. And the person doing that role may change over time. The person doing that role might even be different for different areas of the product. AND this is ok.
If you find yourself in this situation, be clear on who is responsible for each thing. Have a conversation about who will play each role so everyone knows what is expected of them and who is responsible. Having some sort of indicator is also helpful – a hat, an emoji, listed on the wiki page, etc.
Ever had a founder or exec approach you with an idea they got from a competitor’s webinar or something their friend told them about (the old ‘airplane magazine syndrome’)? The person telling you about this and asking why you aren’t working on the same is coming from a good place – a place of trying to keep the company afloat – though these conversations can be distractions to the strategy.
You want to have a productive conversation that doesn’t create tension between you & this person. You want to frame the outcome for the business and the team, not talk about how important the discovery is.
Nick referenced a talk by Kirsten Mann at LTP where she talked about executives want certainty. You might feel like showing your work will help them understand but really you want to remove the language of product & design from these conversations and focus on the commercial acumen – what is the expected impact?
Another way to frame this comes from General ‘Salty’ Saltzman from the US Space Force. He wants to know what is your theory of success. You should be able to tell someone what you’re trying to achieve and how it will help achieve success.
Nick suggests using the language of ‘bets’ to get out of our jargon and move more towards risk, portfolio of bets and that losing might be an option. This also helps to move away from the conversation of when something will be delivered but should we back other bets or continue to continue to back this bet based on the data we have gathered. He then shared a great conversation he had at one company where ‘getting to parity with a competitor’ was being encouraged and Nick asked what would the impact of ‘parity’ be? Would it get us every deal? No. Would it get us half the deals? What if we did something different that solved a real problem that could help us win more than half the deals? How long would we fund this bet? How long should it take us to understand this bet? This conversation led to a new strategy with a new market to sell to.
Managing your career growth if you’re the 1st (or only product manager)
You might have dreams for your product manager career – getting promoted, earning more money, whatever you dream of. That might not be the reality you work in. You might not get great feedback (keep doing what you’re doing!). There might not be the opportunity for promotions or not a clear idea of how that would ever happen (keep deliverying value says the boss). You probably gather your data from salary surveys and put forward your case but if the organisation doesn’t have the money, they can’t give you a raise.
This does not mean you can’t continue to grow! You need to create your own path. Nick is creating a growth framework for his team which explains the competencies for a PM at different levels.
Nick reflected on his own dreams of presenting his roadmap to the board right after starting his new job. He was advised by that 1st you need to show that you can present it to your team and that they understand the vision and how they contribute to that vision. If you’re doing well with the team, then the next step could be to present to the company at the next all hands. Think about what are the levels you can do this at and how you can stretch and grow.
Nick Wodzinski is the lead product manager at Chargefox – Australia’s largest public charging network for electric vehicles. His background is in construction tech, and he has worked setting up product teams with startups and scale ups over the last 5 years in the Australian software industry.
Our Host
Our wonderful friends at Everest Engineering will be our hosts for the evening.
Everest Engineering: A bold, people first community, building digital products for those who do things differently.
What is the difference between a product team building a product and product teams ‘doing product’? As software companies scale and the product team grows, the difference between building ‘stuff’ and performing the practice of product management can be massive. It can greatly impact the ability to find product market fit through to the ability to scale with pace and grace.
Our speaker, Nick Wodzinski will share his experience of going from product hire #1 in startups & scale ups and working with teams building product to setting the formula for growing from 1 to many product teams. Nick will reflect on his experiences of setting up teams over the last 5 years with SignOnSite, EstimateOne, Mastt and Chargefox.
Our speaker:
Nick Wodzinski is the lead product manager at Chargefox – Australia’s largest public charging network for electric vehicles. His background is in construction tech, and he has worked setting up product teams with startups and scale ups over the last 5 years in the Australian software industry. Fast 5 Q&Awith Nick
Our host: Our wonderful friends at Everest Engineering will be our hosts for the evening.
Everest Engineering is a bold, people first community, building digital products for those who do things differently.
As a product manager, have you gotten caught into the AI frenzy? Or feel like you’re missing out and not sure where to start?
This month we’ll talk about how to make use of AI and tools like ChatGPT in your product world. RSVP for September 21st
– How to use Generative Ai in your workflow, i.e. pad out a persona
– How to incorporate it into an existing product i.e. Shopify launching Sidekick, a personal commerce assistant
– What could you do to build from the ground up with chatGPT, as an example. i.e. this is the hardest to predict at the moment as well but we can explore some of the future opportunities
Our speaker:
Tim O’Neill is the Co-founder of Time Under Tension. They help companies make sense of Generative AI and how it can be used for their products.
Catapult exists to unleash the potential of every athlete and team on earth. Operating at the intersection of sports science and analytics, Catapult products are designed to optimize performance, avoid injury, and improve return to play. Catapult has over 400 staff based across 24 locations worldwide, working with more than 3,800 Pro teams in over 40 sports across more than 100 countries globally. To learn more about Catapult and to inquire about accessing performance analytics for a team or athlete, visit us at catapult.com. Follow us at @CatapultSports on social media for daily updates.
