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.
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.
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:
When Aaron Hardy first moved into a product leader role at PageUp, he needed to take stock of the situation, and work out where to focus his efforts first. Were there changes to make to the product? Did they have an adequate strategy to guide them? Or should he begin with his team?
After speaking with his new team, one area Aaron identified as lacking was a capability framework or career ladder. How were the team to know how they were performing? What steps would they need to take to move to the next level?
The team had already been through multiple restructures, with various leaders coming and going. And with that, each time the team would inevitably end up having to explain what they did, what value they brought, and justify why they were needed on the team. Would he put them through that all again?
Taking inspiration from Ben Horowitz (and Jim Barksdale) Aaron decided to start with his people.
Step 1: Researching Capability Frameworks
Before jumping straight in to create his own capability map, Aaron researched the existing frameworks already available. And there were plenty out there. However, none of them quite fit what he was looking for.
Intercom’s framework has been shared quite extensively, and does a great job to show how to level up as a product manager. However, they have a very different business model, making it difficult to apply to PageUp.
The Association of Product Professionals had a good structure, demonstrating external (market) vs internal (operational) aspects. However, it was a little too heavy for what they needed. Aaron needed something simpler for his team to use.
Pragmatic Marketing Framework: Looking outside of direct product management, Pragmatic gives a good visual of broad capabilities. It also helps you evaluate what you’re doing and what you’re not. Then giving you the opportunity to assess if you think those gaps are important.
Aaron wanted to find something that was relevant to the way they did product. Something that his people could relate to, and use in their day to day activities.
Step 2: Product Mastery Levels
After having a good view of the different skills needed, the other side of a capability framework is how many levels you need. Where is your company at, and what’s right for them?
Also, it has become more common for companies to recognise and support different career tracks for:
individual contribution; and
people leadership.
Wherever you land, remember – it’s for a point in time. As you grow and mature, you may need to extend the framework in the future.
You should also consider the different types of product work, from:
Feature Work
Growth Work
Scaling Work
Product Market Fit Expansion.
And the different possible paths into product.
Beyond the obvious Product Owners or other product adjacent roles, some other sources to grow your talent pool could be from support, operations, consulting, marketing, psychology, research, entrepreneurs, and many more.
Step 3: Making it Bespoke
The next stage is to try to pull it all together:
Mapping out all the skills;
Removing the irrelevant ones;
Finding the duplicates; and
Ranking what is important.
Hot tip: Making things visual can make them easier to understand.
However, then comes the hard part:
Mapping to your own framework:
Writing descriptions for each capability. This will eventually be incorporated into Position Descriptions, so some things to consider would be:
What is expected at each mastery level?
How are the different mastery levels mapped to different roles?
How would people demonstrate their capability?
Socialising:
How does your capability matrix align with other disciplines you partner with (eg, UX)? It’s good to gather feedback and support from your peers, senior team members; partners and possibly even senior leaders.
Input from the team:
You can also include the team. Have them help with the descriptions and differentiators. Rank the importance of each capability. Get them involved so they can contribute and shape the result, making it easier to create buy-in.
Ways to Level Up
Once you have your shiny new capability framework, it can help provide clear guidance for the team of what’s needed to reach the next level and they can do one of many self-assessments available online.
But how can they actually level up?
There are plenty of methods are your disposal:
Formal training or courses – to either learn new skills, or revalidate existing skill levels;
Observation – following product leaders on social media;
Starting from their grad program, and soon proliferating throughout the rest of their teams, new Reece employees are given an induction like no other. They are sent to one of the 644 Australian branches to immerse themselves in the business.
It’s back to apprentice mode, as you get first hand experience of the customer sites. The 7am morning rush, helping setup customers, picking and packing orders which come in from all areas (overnight orders, phone, app and in-person), receiving stock, organising deliveries, reporting back when things don’t go quite right. And seeing Reece’s customer obsession service standard for yourself.
Not just for research purposes, or standing on the sidelines taking notes. But by working side by side with the branch staff, serving customers.
Everyone has done Branch Time.
Even the CEO.
How long can vary for different areas, depending on their needs. But the standard stint for a Product Manager is around 6 weeks.
The Pros and… More Pros
But sending every new hire to Branch Time is a serious commitment – in both time and dollars.
So what’s the upside?
Firstly, accelerating your understanding of the business, and building a strong foundation to make decisions in the future. This is not always tangible or measurable by reporting, but what better way to fast-track your decision making capability?
Also, forming connections and relationships with the branches, and understanding the mayhem of retail. You even get direct experience with using Reece’s internal systems, such as TRS. You always have access to feedback, as you’re constantly in contact with branches.
And, of course, establishing deep empathy with your customers, the majority who are tradies. Understanding and becoming intimate with their customer problems, so you can ensure the right solutions are developed to deliver the right outcomes. Knowing their world also enables you to contribute and create meaningful OKRs (targets).
But it doesn’t stop there:
Branch managers and staff also benefit from building relationships with somebody in head office.
After Branch Time, you have ongoing access to the branch network, to continue to foster relationships, to interview or to validate ideas and concepts with staff or customers.
New team members also go through the same Branch Time experience, so there is a shared understanding and common ground established.
What was your most embarrassing moment in product?
Pearly: I haven’t had many embarrassing moments… When you galvanise the team towards a direction. You’re bold, and push the boundaries. But then after you launch, things don’t work out as planned, and you need to acknowledge the fact with the team, and then try to pull them in a different direction. It can definitely feel embarrassing in the moment, but you also learn a lot from it too.
Tom: Early in his career, while working at a startup, Tom was encouraged by his Head of Experience to hit the street and interview people. After buying around $300 of prepaid coffees from a local cafe, and approaching people with a coffee for their thoughts, people were so preoccupied and busy, Tom couldn’t even give away the coffee cards.
Brendan: Similar to Tom, an early experience for Brendan involved canvassing a local university to survey students about healthy habits… for Breast Cancer Awareness week.
Advice for Product Managers early in their career to accelerate their learning?
Tom: There is no perfect way to do product. Holding a (‘right’ way to do product) view usually does not lead to a productive outcome, and instead can prove divisive with your team and/or management. As an alternative, focus on how you can help the company fill the gaps that it may have.
Pearly: You can also create a capability map, plotting competencies from tactical to strategic, and skills from technical to sales and marketing. Then you can assess where you are, and identify which areas need development.
Brendan: Find a mentor who can help you identify where you need to grow.
When should you seek a mentor, and what should you look for?
Liz: As soon as you start in product!
Brendan: Or even before you get into product.
Tom: Tom approaches mentorship differently, more transactional rather than a relationship. He has around 15 mentors, who have different experiences and expertise. So depending on what specific advice Tom is after, he will access his most appropriate mentor.
Are certifications such as CSPO or Pragmatic important?
Pearly & Tom: Can they make you better? Sure, they can help. Especially for interviews. However, are they essential? Probably not. They shouldn’t be definitive. They may, however become the new benchmark in future.
Tom: For individuals, you can mash up information from a variety of sources to get what’s needed. From a corporate (or team) perspective, it can also help to form a common language.
Brendan: The less dogmatic about how you are certified, the better. If a recruiter has agile or product certification as requirements, then that in itself may be a red flag, as they may value the certification so much.
What’s a reasonable 90 day plan for a Product Manager who just joined your team?
Pearly: It usually takes substantial time (eg, 6-12 months) before getting a return from a new product manager. You shouldn’t rush in to make changes. Spend the first month observing, and formulating your plans. Don’t fall into the trap of making decisions without any information.
Tom: The best product people are those who have good relationships with their co-workers, as there will be plenty of communication and negotiation ahead. So meet your co-workers.
Also, get closer to the product. Use the product. Sit in with the customer service team. Use the systems that your support team are using.
Brendan: When you start a new product role, begin with a fact finding mission. What data is available. What are the strategies?
How do you convince senior execs or founders that not everything needs to be in JIRA?
Pearly: I had previously been really strong about not believing in templates. It’s not about templates, but the thinking behind it.
When people don’t know how to communicate effectively with each other, sometimes tooling can reduce collaboration, eg, I work on my tickets, and reassign them instead of communicating. However, standardisation can help create a shared understanding and common language.
Tom: Using Jira, and not fighting the structure can also be freeing. Instead of spending your energy on continuously striving for the perfect template, you can instead focus on actually making better software.
Brendan: As an agile coach, I do not want people to blindly use the tool or follow a process, without understanding the intent behind it.
When was a time you killed a product or initiative?
Brendan: Sometimes the strategy evolves, and products (which may have been loved) are no longer aligned with the new direction. Decommissioning can be necessary, and also freeing. It definitely made our developers happier, so they had one less thing to support.
Tom: At one client, we explored a bill scanning feature – scan a bill, use OCR to read the details, and feed into a rules based engine to derive a comparison. What started as a two week block of development quickly became 6 months of trying to get it to work. But it never worked. There was 0% conversion. It was not only about the time and money spent on this feature, but also the opportunity cost of all the things we were not building, because we were focused on this feature.
Pearly: When I worked in publishing, one of our products, the Business Review Weekly, was well regarded, however not making any money so we had to decommission the brand and product and created a new Leadership Section to the AFR. It was a great experience because of the amount of work required to decommission such a legacy.
Why did you get into consulting?
Tom: For me it was about the scope of work, and exposure to so many different companies and industries. Lots of other varieties.
Pearly: I like change, and a way to learn different things. I have the opportunity to observe how product is practised in different ways across different organisations, but also see similar problems.
Brendan: Like the others have mentioned, the variety. But also, personally, it was a lifestyle choice. Being a contractor or permanent employee can sometimes be all encompassing. Whereas consulting allows the freedom to go off the grid and volunteer for a week.
Where do you see the future of Product Management in 10-15 years?
Brendan: Hopefully there will be much more empowerment. What’s the point of people spending so much time and energy to get close to the problems, and get insights, but are then not empowered to make the decisions? They need to be trusted and empowered to make the decisions.
Pearly: Product Management will become more ingrained at the upper levels. More people will be able to recognise what good product management looks like, and understand the value of being product-led.
With the ever increasing focus on Environmental Social Governance (ESG), organisations are tasked with developing strategies to create long-term and sustainable value. Rarely a simple task in our rapidly changing world, needing to balance a broad range of stakeholders, from employees and customers to investors, suppliers, community groups, and our societal and environmental obligations at large.
Extending beyond ‘because it is the right thing to do for our environment and planet’, there are various commercial risks for not taking ESG seriously:
Growing focus on the Environmental part of ESG policy;
Supply chain volatility;
Evolving legislation;
Investor priorities;
Attracting talent; and
Brand association.
But remember, where there are risks, there are also opportunities, where you can use these attributes to differentiate yourself from the rest of the market.
Where to start?
The transition to sustainability can feel overwhelming at first. The task can seem insurmountable. So where should you start?
Begin with monitoring and tracking your emissions.
There are many software options available for emissions monitoring, data collection, and sustainability reporting. Many can also help in strategic planning and decision-making by analysing historical data to provide insights and predict the future.
Make it bite size.
Like most things, break down the problem. Begin with small steps to build some momentum. Canvas opinions from others, and find internal partners to gain support, working your way up the chain (ie, don’t go straight to the CEO).
Work with your timelines.
There can be many challenges in a corporate setting, such as having contracts with existing suppliers. But rather than fight against the system, look for a path of less resistance. When is the contract due to expire? A month before the expiry date, conduct a review for alternative options.
Keep climbing the ladder.
Change won’t happen overnight. As you start to make some progress, keep going. There is always more than can be done.
You don’t have to work on a climate tech product to make a difference with the environment.
Additional Overlooked Opportunities
There are many opportunities to improve, and move towards a circular economy. Try not to only look at the obvious things. Widen your view and look beyond what is just in front of you.
A few things to consider:
Data storage: storing information, emails and backups all require servers and the energy to power them. Is it time for that retention policy to be reviewed?
Reverse logistics: Instead of products ending up in landfill, can they be re-acquired, refurbished, and resold? Not only does this reduce our waste, but it can also generate an additional revenue stream.
Waste management: Companies spend money to deal with their waste. However, reducing the amount of waste also provides an opportunity to alleviate that cost.
As a Business or Product Analyst? Product Owner? Or Product Manager?
We all start from different places, and our paths for growth are varied.
In July, Adam Wensor, Craig Brown and the crew from EverestEngineering joined us to run an interactive Career Development Workshop, where we co-created a development framework.
The challenge
For many of us, we stumbled our way into product. Our early days spent trying to work out what we’re supposed to be doing. Slowly building in some reps, and some muscle over time. Eventually feeling more comfortable with the work.
But how can we objectively assess ourselves?
And what sort of things should we work on to improve, and level up?
How might we build a roadmap for ourselves?
Product Management Competencies
What are the core competencies for product management?
This can be workshopped with your team. Alternatively, we leveraged a few experts in the field:
Roman Pilcher;
Marty Cagan’s Silicon Valley Product Group; and
John Cutler
Next, we grouped the competencies into themes.
Then, we considered what different levels of mastery may look like?
Like many workshops, it was as much about the journey rather than the destination. However, with a broad mix of tenure in the room, it was a great opportunity to reflect how things can feel earlier on in our careers, and to gain some insights from those who may have more experience.
