OKRs in Real Life – May wrap-up

Objectives & Key Results. Do they really deliver on the promise? Will they help you reach your goals?

We enlisted 3 product people to talk about their experience of using OKRs to see how they work in real life.

Our speakers:

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

The OKR Process

Andrew let us know that every team at Seek manages their OKRs a little bit differently & they’re currently in their 4th or 5th quarter of doing OKRs.

Andrew described a very team based approach (which is what Wayne also talked to). About 6 weeks before the end of the quarter, the teams receive some context on where the business is going & what they’re seeing in the market. About 2 weeks before the end of the quarter, the team incorporates their own research & knowledge to create draft OKRs for the next quarter. Drafts are reviewed to ensure they are aligned across the portfolio.

Setting OKRs is only part of the process – you need to understand how they went & learn from them. At Seek, there’s check-ins during the quarter (even just emails) and at the end of the quarter, teams present how they went for each OKR, what that means for the roadmap & strategy going forward and what the next set of OKRs are. REA has a mid-quarter update to ensure you’re on the right path or if there’s roadblocks that need to be cleared.

Wayne reminded us that part of the process is needing to educate your team about OKRs. Some people might think they are tied to performance or compensation so you need explain how the OKRs work. As the acceptance of OKRs builds across the business, you need to keep educating different groups.

And Brad noted they do not follow the usual quarterly OKR cycle! They work to a 6 week plan because that’s what works for them.

What works well…

There was clear agreement between our speakers that OKRs can create alignment between teams & stakeholders. They set expectations on what to do, not how to do it. They force prioritisation early on. They help people understand why you did X and not Y. Brad believes they are great for helping people believe in something & getting people to rally behind something.

Wayne believes they help speed up decision making as the product manager doesn’t have to answer everything. People on the team know where they are headed which drives performance within the team.

Based on what our speakers said, it seems they can also help raise issues. Use the OKRs to help show when a deliverable (that’s been delivered) needs some help. If a senior stakeholder says to build X, use the OKRs to manage if that’s the right thing to build.

Brad uses a combination of focusing on outcomes and PIRATE metrics to drive OKR setting.

What’s not working…

Creating your OKRs can be tough. You need to provide enough context for the teams to make good OKRs. Don’t have too many – recognise that even 3 objectives can be too many and 26 KRs is definitely too many. Changing the objectives every quarter can be too much context switching with not enough time to make real progress. They should not be a task list.

Wayne said they realised during planning that they had 3 objectives that were exactly the same thing but had been written in 3 different ways. The team used 3 1-hr sessions to get all their ideas on post-its, all the concrete ideas out and used that to help think at a higher level (& get the entire team onboard).

Make your OKRs part of everyday life can be a struggle. What do you do if half way through the quarter you’ve smashed it? or realised it’s not something you should do.

Measuring your OKRs needs to happen. Wayne advised us NOT to have a set & forget attitude. He suggested setting up your measurement plans in the 1st week. AND not to use surveys to measure everything as there will be survey fatigue from customers & internal folks.

Don’t focus totally on the OKR. Brad finds it fascinating that people really focus on the OKR.. what’s a good one, what’s a bad one. He sets them and then focuses on the outcome.

Mental Contrasting

Brad talked about the concept of ‘mental contrasting’ which consists of 4 items and the first 2 are tied to what an OKR is.

  • Wish – the inspiring thing you’re going for ie your objective
  • Outcome – your KR
  • Obstacle
  • Plan

With mental contrasting, you should take a little time to think about the obstacle. Just thinking about it, helps you act.

FYI, this is also called ‘WOOP‘ (easier to remember than mental contrasting!)

Questions

What’s the worse KR you’ve seen? Andrew: “TBC” Brad: putting in an OKR we knew we couldn’t meet – or vanity things.

How long does it take to pull together OKRs? Brad says it’s about 2 days (every 6 weeks). Andrew says it’s much less now that they have done this several times and they don’t change their objectives every time. Wayne has time boxed theirs to 3 hrs.

Wayne & Andrew also talked to the difference between old & new products. New products might need longer to work out the OKRs as opposed to tweaking existing products.

Thank you!

A massive thank you to Andrew, Wayne & Brad, our wonderful speakers for the evening! To our fantastic volunteers for the evening: Gwen, Steve C, Steve B, Rob, Neha, Nigel & Marija. To all attendees!!! And to Medibank for hosting!!!!

Slides: Andrew Knibbe / Seek

Slides: Wayne Allan / REA

Slides: Brad Dunn / OHNO

The What & Why of Wardley Maps – The wrap-up

I first heard of Wardley Mapping about 2 months ago and then the name started popping up in a few places which got us investigating it as a potential topic. Coming at it from zero knowledge, it seemed like the sort of thing product folks should know more about as it concerned both strategy & decision making.

Kim Ballestrin, Principal Consultant at elabor8, talked us through the basics and got us creating a map by thinking through the user needs capturing & protecting their personal data when using social media.

The What of Wardley Maps

A Wardley Map is a representation of the landscape & environment a company operates in. Its creator, Simon Wardley, believes a leader should have a map of the terrain to help guide their strategy.

The map consists of the activities the user needs to accomplish their goal charted across lifecycle, supply & demand.

You can use this framework in several ways, such as:

  • To think about your ongoing product development – from USP to commodities
  • A way of looking at the market or competitor landscape
  • Process and value chains from understanding where you have no standard process to defining a highly standardised process

The Whys of Wardley Maps

The map is a great way to create discussion. Once created, scan your map from top to bottom and left to right to determine if there are specific decisions that need to be made. Look for assumptions you’re making on the map or within your existing thought process.

Bonus – The How of Wardley Maps!

There’s a few principles to keep in mind when creating a Wardley Map:

  • The user need is your starting point
  • Keep it simple and on a small scale – don’t try to map EVERYTHING!
  • Your map will be imperfect – and that is completely ok!

How to create a Wardley Map

  1. Define your user’s needs.
  2. What are the activities the user takes in order for those needs to be met?
  3. Drill down into functions & features based on the visibility of the features to the end user.

Chart your functions & features from left to right along the evolutionary axes. The axes go from bespoke (genesis) on the left to generic (commodity) on the right.

Sketch in the linkages between the features & functions. This gives a good landscape of where you are right now.

Mapping out these connections and perhaps seeing where you may be too dominant in your commodity space & thus are at risk of disruption. Or understand that you’re too heavy in custom services, which bring high cost to serve & thus its time to consider streamlining the business by moving those to a product stage. These are some examples of ways a Wardley map helps you see the landscape and make better strategic decisions on what to do next as an organisation.

ProdAnon also had a bit of a surprise! The man himself, Simon Wardley, creator of this framework just happened to be in Melbourne Thursday evening and attended the session. Thank you Kim for inviting him!

Simon was kind enough to take some questions from the audience & talk through how he came up with his framework all those years ago.

Thank you to all the ProdAnon volunteers!! Ana Roy for fantastic note taking (& the great sketches!), Steve Cheah for the pix & elevator work and a these amazing people: Gwen D’souza, Marija Becker , Rob Finney, Richard Burke, Neha Jaiswal.

A massive thank you to DiUS for hosting the evening!

DiUS

Thank you Kim for the talk & organising the surprise appearance by Simon!

Resources

Strategy for Executives – Situation Normal, Everything Must Change

Simon Wardley’s ‘Wardley Mapping‘ site

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

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

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

David Bignall / Seek

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

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

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

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

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

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

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

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

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

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

Dave’s top tips for roadmaps

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

Whitney Cali / realestate.com.au

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

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

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

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

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

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

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

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

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

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

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

Keith Swann / Origin Engery

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

His beliefs are that they help with:

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

Alignment

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

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

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

Takeaways

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

Summary

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

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

Thank you!!!

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

gather
UnitedCo.
seek.com
Brainmates

Sharing your (startup) baby with the 1st Product Manager – November wrap-up

What’s it like to start a company & then bring in a product manager? How do you know when the time is right?

We gathered 3 founders to talk about sharing their baby along with 1 product manager who’s the 1st PM at a startup to facilitate!

Our panel was Danielle Bodinnar, CEO of Karista, Rod Hamilton, founder & VP of Product at Culture Amp, Linus Chang, founder of 2 software companies (Backup Assist & Scram Software) and our facilitator,George Tsigounis, from A Cloud Guru.

Trust came up very early in our discussion. For CultureAmp, trust is part of their company values and differences of opinion is a good thing. When you challenge things, it’s from a good place. Karista has 1 product person & Danielle was super impressed by the research and prep the PM did before their 1st meeting – which quickly earned her trust. Linus talked about the differences people have in the way they think of earning trust. Some people start from a place of trust while others need to build it up.

When did they realise they needed a product manager?

Rod went to the rest of the founders & said he needed to start hiring because he was getting slammed. Some of the other teams at Culture Amp, including technology, had scaled up previously so it wasn’t a surprise when he came to the realisation. Danielle brought on the 1st PM shortly after launch. As a solo founder, she needed someone she could hand stuff over to and know it will be done.

Why are product managers needed?

Danielle laughingly said she doesn’t know what a product manager does (as in what the job description should include) but she knows the only product manager at Karista gets stuff done!

One of the reasons Linus realised they needed a product manager was no one was paying attention to trends of the market & what opportunities were out there. They had a product owner who was internally focused & worked closely with the dev team but only he & his business partner ever talked to customers. He sees the product manager as being visionary as in really knowing customer needs, not just what the customer says they need.

The ‘special’ deals

Startups often have the ‘special’. That thing(or multiple things!) that was built for the 1 customer so the business can get the revenue or a specific client or (insert reason). It’s completely sales led, isn’t validated as a customer need and often ends up with code that says ‘if customer X, do this’. Saying yes to a special for 1 customer is saying no to all the others so if you’re going to do this, you need to put it in context – communicate clearly with the team why you’re doing this.

Later Rod reminded us that it’s the product manager role to ‘win the market not the client’ & quoted Gibson Biddle’s definition where our job is to delight customers, in margin-enhancing, hard-to-copy ways (from Gibson’s Leading the Product talk )

Scaling the product team

Beyond the 1st PM, you will need to scale your own team. Culture Amp now has ~ 9 product people and is continuing to grow. They are creating product rituals like a Monday catchup to review the week’s goals and one on Friday for the team to talk about what went well/not well during the week (a bit of a therapy session).

Now that there are several PMs & Rod isn’t involved at the same level as previously, he sometimes wonders why X was prioritised and knows he would have done X differently but has to let go of those decisions. The team has built trust amongst themselves so when Rod does challenge something – it’s a positive thing & discussion to follow.

Lastly, a few tips for startup product people from the founders: (which apply to all product, not just startup!)

  • Don’t just talk to existing clients, know the potentials too
  • You need to constantly be in touch with customers
  • Don’t assume growth is not your job
  • Be commercially minded

Thank you to Culture Amp for hosting!!!

Culture Amp logo

Bringing Human Experiences to work – September wrap-up

What does it mean when we say we’re ‘bringing human experiences’ to work? And why should we?

Gin Atkins, Head of Product at The Conversation kicked off the evening with:

We know people are at the core of what we do. Yet, our best developers, designers, and product managers are rarely able to talk about people with as much confidence and nuance as they talk about ruby, typefaces or commercial strategy.

Over the course of the evening, Gin introduced us to 3 ways to help draw out experiences & bring them into our work.

Energy Graph – a tool to help us think and talk about experiences.

The energy graph is a tool used in acting to show the spectrum of experience. Gin learned it from Paul Currie, the co-founder of The Reach Foundation and Lightstream Entertainment.

Using several clips of music, Gin had us mark how each music clip made us feel on the graph & compare with others sitting at our table. There was definitely differences in what made us happy or sad and how energised (or not) it made us feel. Though apparently I’m the only person who gets annoyed by the Lion King soundtrack! To contrast, one attendee recounted how the Lion King brings up memories & great feelings of her daughter based on past experiences and you could see how happy she was as she told us about this. Imagine the 2 of us in a workshop where the Lion King soundtrack was playing in the background… she’d be in a great frame of mind where I’d be feeling agitated. Could that affect the results of the workshop?

Think about how music affects you. Consider a song you hate vs one you love vs one that is unoffensive. To bring this back to the office, how do the meeting rooms make you feel? Does your research participant or client feel comfortable?

You can see the graph in the slides below.

Levels of Emotional Design – a framework

Next Gin talked about Don Norman’s 3 levels of (emotional) design which provides a framework to document experiences.

This combines how a product looks & makes us feel when we engage with it (initially & ongoing) with our conscious thought about the product (for example – does it represent what I want to project to the world?)

Gin likes to use Jobs to be Done instead of User Stories to capture these elements. She feels there’s too many assumptions in the ‘As a…’ and ‘I want to…’ of user stories. A JTBD statement focuses on the situation, motivation & expected outcome – ‘when (situation), i want to (motivation) so I can (expected outcome)’.

Using the classic MP3 player example, Gin showed how using emotional design changes what you build.

functional description – When I’m listening to music I want a device that holds all my music so I can listen to anything at any time.

emotional – When I’m listening to music I want a device that looks good so I feel as cool as the artists I’m listening to

Draw on your own experiences – a call to action to help us get better

Drawing on anthropology, there’s etic & emic research of groups.

An etic view of a culture is the perspective of an outsider looking in. This can be problematic as people act differently when they know people are observing them.

An emic view of culture is the insider’s view – when you are part of the group. This is where we are with our teams, in our work lives.

We can use our insider’s view to bring more human experiences into our work & our products.

Thank you to Gin and Carsales, our host for the evening!

FYI, with Leading the Product happening in October, the next Product Anonymous event is November 22nd. RSVP here.

Resources
Also mentioned during the evening – the Overton Window

Leading the Product Pitchfest – July wrap-up

We hope you’ve heard about Leading the Product – the fantastic product management conference Down Under.

We teamed up with the LTP folks to hold a pitchfest for lightning talk spots and we’re thrilled to announce Daniel Kinal & Shiyu Zhu will take the stage in October!!

Thanks to everyone for supporting the folks who pitched their talks, to Seek for hosting, for Leading the Product for the great idea and to our judging panel – Adrienne Tan of Brainmates/Leading the Product, Mark O’Shea of Seek and Dan Johnston of CultureAmp.

Before kicking off the pitches, we had a few of last year’s lightning talk folks – Liz Blink, Katherine Barrett & Zac Andrew – to tell us what it was like and give us a few tips!

  • Know your beginning and end! Give yourself some time to ad-lib in the middle
  • Good memes at the beginning & end help
  • Practice, practice, practice, practice!
  • Know how fast or slow you speak when you’re in front of people.
  • Focus on the content of the talk first and the slides second.
  • Props are your friend
  • Bring a story to life
  • Have 3 things the audience can walk away with
  • That sick feeling you have before getting up on stage is a good thing – it’s excitement!

We had 10 pitches on the evening – including a last minute submission! They were all fantastic!! Leading the Product only had 2 spots available so we hope to hear these other talks at Product Camp Melbourne in August!

Get your tickets to Leading the Product before they sell out (which they do every year!)!

Thank you Seek for hosting!

Our next event is Product Camp – register now and submit a pitch!

Every Product is a Service – June wrap-up

We gathered a couple people who work in product and a couple people who work in design to discuss if every product is a service and how we can work together well.

This would not have been possible without Service Design Melbourne & NEXT, a division of the Reece Group, who kindly sponsored the evening.

To introduce our panel, we quizzed them on their qualifications…
Dave Calleja – Associate Design Director at Isobar. Has a degree in design.
Kate Edwards-Davis – Product Manager at Karista. Studied classical music performance & philosophy.
Dr Stefanie Di Russo – Principal Designer at NAB. Holds design degrees including a PhD in design thinking.
Daniel Kinal – Product Manager at MYOB. His degrees go across economics, accounting, marketing and a some information systems stuff.

And our moderator – Liz Blink – Digital Customer Experience Manager at Department of Environment, Land, Water & Planning VIC Government. Holds a PhD in immunology.

Which goes to show we work with people from very diverse backgrounds & there’s different avenues to getting into the work we do.

First we surveyed the audience to see which camp they belonged to… service design, product, something else or multiple areas. 57% of our audience said they were something else! From the shouts from the audience, it seemed a lot of folks identified with ‘UX’.

kicking off our session with service design melbourne #prodanon

A post shared by Product Anonymous (@product_anon) on

Dave raised the definition of ‘product’ and how you can’t really divide up things like Netflix into those definitions of ‘product’ or ‘service’. Do you think Netflix is a product or a service? He feels to discuss the two, there needs to be some semantic mud hurdling.

Steph pointed out that service design has a time element with artifacts and actors while product is the artifact itself at a certain point of time.

While Daniel thinks it’s all ‘product’ going across goods & services lines. If we are talking about eating a mandarin for breakfast or getting a scalp massage there’s a clear ‘product’ or ‘service’ in those definitions but we probably all work on complex products which have both tangible & intangible elements. There is a basket of benefits you’re offering the end customer.

Kate asked ‘who cares?’. The outcome is the important thing! We’re trying to package something together to help meet a customer’s need. ‘Products’ co-exist with ‘services’ and we even buy some ‘products’ despite the ‘service’ we receive with them.

Kate brought a prop along to prove the point that a ‘product’ or good can always be improved when you think about the ‘service’! Who Gives a Crap is toilet paper that’s been wrapped in a ‘service’. They offer a subscription service so you never run out and they are focused on social good by being environmentally sound and donating profits. They are disrupting with their ‘service’.

There was lots of talk of physical products – mandarins, toilet paper and then coke! Steph discussed the difference between a ‘service’ and an ‘experience’. The taste of the coke is part of the ‘experience’ while there’s actors & elements that enable the ‘service’ to exist.

But Dave brought it back into the realm of the digital (which most folks in the room work in…). When you are using a digital ‘service’ like Netflix, there’s definitely a physical attribute which might be sitting on the couch, having a tablet or remote in your hand. It’s how the end user experiences this, how the end user views that as the product. What words we in the industry use to discuss it isn’t as important as the outcome.

Service design is a design methodology & an approach to tackle problems. There are lots of frameworks & ways to understand problems and each discipline (product, design, marketing, etc) will have preferred ways. You can have customer experience people who do not use design methodologies and may rely more on marketing.

Daniel sees the rise of design thinking as a level of maturity in seeing the value of not going right to a solution and looking for ways to truly articulate the problem.

There was some discussion on how good ‘service’ can recover people when they have a bad ‘product’ experience. The ‘service’ element is what helps to get the good online reviews.

Steph asked Daniel if a good product person should have a design background which lead to a discussion about working together.

Everyone agreed a team needs to exist which brings different perspectives and skill sets. Kate brought up the skill set of being able to deliver a product at a price point that will sell & the act of using the organisation’s capabilities. Daniel discussed one of the responsibilities for a product manager is to be the advocate for the stakeholder who is not in the room (including the customer). Dave said if the team isn’t considering viability, feasibility & desirablity together, you’re unbalanced. Steph focuses more on the desirability while working with product people but is also thinking about the other two.

Healthy debates where you’re not so dogmatic about your position are best said Steph. Daniel wants designers to have a different perspective and be even more customer driven than he is so they can have creative (good) conflict about the different ways to reach a specific goal. He’s found that the more experience a person has, typically they have a level of maturity that allows them to leave their ego at the door about whose idea it was but at the end of the meeting, you are all focused in 1 direction.

Kate recommends spending time together to understand the customer & strategy. What a person’s title is doesn’t matter as long as you are there to learn & understand from each other. Dave also mentioned psychological safety of having those conversations & suggested leaving the drama to Love Island, not the office.

Thank you to NEXT, a division of the Reece Group and Service Design Melbourne for a wonderful evening!

 

Check your bias at the door – May wrap-up

A cognitive bias is a shortcut your brain takes to make decisions. Cognitive biases can impact our decision making, our memory, the way we interpret research and more.

As product managers need to understand our customers & their needs, motivations, problems (etc), it is a ‘mistake’ to let your lazy brain fall prey to the cognitive biases that make you hold onto your own preferences or beliefs, no matter what evidence is presented!

Our speaker was David Di Sipio, a registered Psychologist and currently working at Squiz as a UX Consultant. David creates great experiences by focusing on what makes people tick. His approach is grounded in academic research, big-data and best-practice.

David ran us through some great examples & how to manage the 6 most common biases:

  1. Selection Bias – who are you talking to?
  2. Framing Effect – the words you use & way you present your questions
  3. Confirmation Bias – focusing on the information that reinforces your ideas & ignoring the ones that disprove your idea
  4. Observer Effect – subconsciously influencing someone with your body language
  5. Anchoring Bias – putting too much emphasis on the 1st bit of info we receive
  6. Clustering Illusion – seeing patterns when none exist

After walking thru these biases, David gave us time to talk thru some of the biases we’ve fallen for & there was a bit of conversation regarding which is our favourite bias!

Want more info? You can view David’s slides or read his article on Medium which also contains the links to all the great videos he showed.

Thanks again to Origin for hosting us.

Origin Energy

We’ve announced our June session – RSVP now for a collaboration between Product Anonymous and Service Design Melbourne discussing ‘every product is a service’.

Does data or design win with product folks? March wrap-up

Does data or design rule supreme for us product folk? When we’re deciding what to work on or how to create whatever we’re creating… which do we lean towards?

To debate data vs design, we gathered a fabulous panel: 

Firmly on the data side was Marty Kemka from Northraine. Marty is a data scientist and entrepreneur. He’s worked on projects where something needed to shift and he says as long as you know the metric & design the experiment properly, the data should be able to show you the way.

On the design side, from Cogent, Amelia Crook is very interested in what human need is being solved and thinks people leave a trail of data but that data can’t give you the insight as to why the person has done something. The why is what gets you to the need.

Also, Steve Bauer was sitting on the design side. Steve also wants to understand the human element, is appreciative of qualitative research & yet knows his way around the numbers.

And finally Jane Register who has a design background and said she was also representing design. She’s previously worked with qualitative research but currently works on a product with lots of data. She has more data available now than ever before and finds that exciting.

FYI Jane & Steve work together at Aconex and prior to the event, Steve thought Jane would absolutely be on the data side. Jane later talked about how as a UX designer, she can’t have data without design nor design without data. For her you need to data to tell you some things but you also need the ‘why’.

We also had a great facilitator for the evening, Jane Scowcroft from Data61.

#prodanon

A post shared by Product Anonymous (@product_anon) on

Everyone had a card to vote if they were ‘data’ or ‘design’ and the initial check suggested most were leaning towards the data side. Our unscientific count was data in the lead at maybe 60% of the audience. The subsequent discussion may have gotten us to a different outcome!?!

Delving into the data isn’t easy according to our design folks. You need to know the context of the questions asked, if the data is spread across different tables or db & there will be back & forth between you & the data analyst in order to even craft the right questions. You can get lost down data rabbit holes. Marty agreed that it needs to be a collaboration with the data analyst because you need to realise there will be database changes to work with, you need to know the context of when an event happened, you have to really understand what you’re measuring and what confidence level you have in all this.

We also touched on using the data to tell the right story of your product. How are you measuring success, what are you optimising for and is that in the context of your product, your department or the entire (especially when large) organisation?

About half way thru the evening, another audience check had us about 50/50 split across data v design.

We see the value of bringing data scientists & analysts into the design fold to help them do their jobs better. Marty recounted a project he worked on where he went out to the field to see how things where done which then greatly helped when he was back at his computer. Over the years it’s been about getting developers to understand the customers more… now we need to bring along the data folks.

Amelia mentioned that looking at an excel sheet doesn’t help you connect with your users. You don’t gain a lot of empathy amongst the cells and rows! Taking folks out in the field so they can meet users is great motivation for wanting to solve that problem for the user.

At the end, the panel couldn’t help itself and admitted needing both data and design to get a great outcome in your product world. I think maybe even Marty started coming around 🙂 And our audience was pretty even 50/50.

Thank you to Jane! Thank you Amelia, Jane, Marty & Steve! Thank you Data61 and Intrepid Group for sponsoring the evening!!

February Summary: Building & Scaling Product Teams with Rich Mironov

We kicked off the year with ‘Building & Scaling Product Management Teams’ because it was one of the most requested topics in our year end survey and it’s something Rich Mironov knows a bit about as he often comes into a company to help them sort out their team (and of course product).

After a quick review of what a product manager’s role is, Rich got right into the team aspect. Both problem finding AND problem solving are team sports, not only for you THE product manager. When there isn’t someone within the business who is knowledgeable about product management, you will find someone is ‘playing’ product manager.

At a startup, the founder who has the passion for the problem & users will often be working on the product. A startup founder has a lot of other responsibilities so need to think about hiring a PM when the sales pressure is increasing, they need someone to help them FOCUS & scalability is needed – often this is somewhere between hitting 12-25 employees. Rich STRONGLY believes you need to bring in someone who with experience at this point – not someone with deep domain knowledge, not someone at the company in another role, not someone with a ‘scrum’ or ‘project’ word in their title but someone who’s been here & done that & has the scars.

At any company, when it comes to building the product team. Rich believes it’s better to reduce the distance between the customer/user, the product person & the development team. His favourite structure for a team is a product person & the dev/ux/design/etc team to be close (physically & collaboratively) with the users via frequent learning conversations. He is not a fan of the customer feedback/problems/conversation filtered via sales or a single product person or marketing, etc.

Which is when we hit the controversial part of the evening – Rich believes the ‘product owner’ job is setup for failure for several reasons including they don’t have time with customers to understand the problems before writing stories & they’re not focused on the end value but productivity focused. Instead of having the owner & manager roles as separate people, it should be the same person doing both roles.

Multiple screens #prodanon

A post shared by Product Anonymous (@product_anon) on

Lastly, we talked a bit more about the different roles in a product team. The product manager should be shipping great individual products, thinking 2-4 quarters ahead & is a relentless communicator of truth. The Director of PM should be focusing on processes, resources & the team. Budget & Strategy, planning for the next 6 quarters & ‘keeping the trains running’ are the focus. A Head of Product/VP is part of the executive team, focusing on aligning strategy, products & the organisation.

Rich’s 4 takeaways for the evening were:

  1. The need for product management is not obvious to a lot of people including founders/CXOs
  2. Hire for product experience
  3. Product Managers own real market value and direct customer learning
  4. The head of product manages the PMs AND the executive team

Rich has posted the slides for your reference and perusal. And for those who couldn’t be there in person check out the full recording of the session.

A big thank you to Rich & Zendesk for a wonderful evening!!!

Zendeskmironov.com