Presentations & Decision Making with Maths – July Product Anonymous

We have 2 sessions in July – our normal event which will focus on using MBA tools (specifically maths) to help make product decisions and a special event about presentations – targeting folks who are interested in presenting at Product Camp.

How to use MBA tools to make product decisions

Thursday July 21st
RSVP

Jen Marshall is someone who didn’t particularly enjoy maths at school, because most of what she was being taught was so theoretical and seemed to have little application. She learned later in life, while doing an MBA, that there are plenty of great ways to use maths in decision making. She now enjoys crunching the numbers.

Jen will share her experiences using financial tools to make product decisions. The session will include examples and step-by-step instructions. Everyone who attends will receive an email with useful links and reference materials.

Jen is CEO at Brainmates, the Australian Product Management training and consulting firm that hosts Leading the Product.

Thanks to Sportsbet for hosting us at their Stadium of Learning!

Nurturing product camp speakers – tips for better presentations

Wednesday July 20th
RSVP

While we’ll be focusing on tips for putting together a presentation for next month’s Product Camp, the tips will work for any presentation that you’ve been asked to ‘throw together’ quickly.

Adrienne Tan, principal consultant at Brainmates, will teach you some of the techniques she uses to create effective presentations. Adrienne doesn’t profess to be a presentation ‘know it all’ but can step you through a process for extracting and articulating your story into a presentation.

This speaker workshop on the 20th of July will share more info about what Product Camp is all about, give you insight and tips about our audience and provide some prep tips and tools for presenting and facilitating.

Thanks To Level 3 and Stax for sponsoring and hosting us:

Level3 Level 3 is all about bringing the creativity back to technology, by generating conversation within the tech community and facilitating introductions between start-ups and enterprises. At Level 3, ideas come to life.


StaxStax shines a light on everything enterprises need to know to be confident in cloud by taking out the guesswork and providing visibility, automated risk assessments, compliance and maturity, and recommendations for achieving best practice.

Letting go of your product – May Wrap Up

While most of us have a fairly long term relationship with our products (as an employee that is!), there are product managers who experience short term product management. They consult in shorter time frames and need to think about what happens after the product goes live and they are not involved anymore.

Suni Stolic, product manager at Cogent, talked about the idea of having a ‘letting it go’ mindset with your product. She admits it isn’t easy!

The analogy Suni used in her talk was about being a mid-wife who ensures the parents are ready to have the baby, they are happy for you to walk away and you are pleased to hear they are doing well – but you have no further responsibility for the rearing of the child.

Via 3 case studies, Suni shared Cogent’s process for building, dealing with product attachment and managing handover including helping an organisation decide on what resources are needed to support the product – and how sometimes they continue to support the product although it’s not quite their baby anymore…

Letting Go mindset

Probably all of us have experienced the problem of the never-ending backlog. The backlog may be full of ideas for making it ‘good enough’ in order to get to launch or fixes for the products flaws.

Suni told us it takes quite a bit of discipline to remember this ‘letting go’ mindset and they help encourage their clients to adopt it, as well as keep themselves in check.

From day 1 of a project, Suni works with the client to be open & transparent (in both directions) including sharing all outputs, having only 1 document (not internal vs external) & equal ownership of the decisions & direction. Co-locating is an important factor for success especially during the development phase.

It’s critical to have a customer first mentality for any product but when you, the product manager, aren’t going to be around for long, you need to be sure what you are delivering will work for them.

Things are unpredictable and so you need to be ready to deploy or be done at any time. Especially in the startup world, Cogent have seen clients need to pause the work in order to reassess the viability of the idea, strategy, business model or other. If there’s going to be a pivot, it’s better to wait & not waste money & resources on something that will change. Funding bursts are another reason they may stop & start.

Case study 1:

Cogent worked with Monash University on the Eliminate Dengue Fever Challenge.

The team needed better tools for collecting data & their field work as they had outgrown Google Docs.

A mobile site, called Tracker, was built for use in the field & data arrived directly in the lab for analysis. What previously took 2 hours for data entry was able to be completed in 20 minutes and it was immediately available for the people at the lab. The application is still used and there’s been only very minimal support needed since the release.

Case study 2:

Taggd is a social to revenue tool for retail.

After building the tool, they had to help the organisation decide whether or not they had the people internally to manage the product development – or continue to resource with Cogent.

It can be tough to hand over a product when you have been involved from the very beginning. You have to retain the discipline to not get caught in the excitement/insanity of thinking about the product constantly!

Case study 3

Having launched only 3 weeks ago, Six Park is in support mode. They built the product which is an automated, really smart way to build a personalised share portfolio with simple 24/7 reporting.

They had lots of good conversations about the seriousness of a product which deals with people’s money – both building the product & providing customer support.

The first response was to go with a high support model but then you determine there are certain windows of time that the tool is actually being used and true 24/7 support is not required.

One person in our audience raised the idea of learning just “how detrimental every card is”.
The Cogent team have learnt the art of asking Why at every opportunity and ensuring each piece of work (i.e. each card) is tied to a goal for the customer. This is a good reminder for us all as I don’t doubt we all intend to do the same but sometimes things get away from us…

Thank you to Teamsquare for the fabulous space, Cogent for food and drink and Suni for a great talk, looking at product management from a different perspective.

teamsquare

Roadmaps: Your Friend or Enemy? Session Wrap-up

We talked all things roadmaps at the April session of Product Anonymous – we had an intro from our three panellists and then we broke into an activity where all our PM’s in the room gathered to build a roadmap for Deliveroo. We only gave them 20 minutes… it was never long enough but we got some great insights from the groups on the pluses of the good ole’ roadmap and the pitfalls to avoid when organising your roadmap.

Our panellists were Adam Fry from Sportsbet, Chris Duncan from Carsales and Matt Kirkey from Learning Seat.

Adam kicked off the session taking us through the positives of a good roadmap – as a communication tool it links the strategic thinking with tactical execution. He suggests it is better to work with the verb “roadmapping” than the “roadmap” as focussing on the artefact loses sight of the purpose. Plus the fact that the artectct is out of date as soon as it hits the printer.

To the plusses:

  • Communication: roadmap artefact is an easily digestible summary of all of the thinking and hard work that goes into planning the future of your product. Your vision on a page
  • Alignment: puts everyone on the same page about what we are trying to achieve, how we will go about it and roughly in what order. Helps give focus to teams involved in the success of the product (delivery, sales, marketing, etc)
  • Buy-in: vehicle for taking stakeholders on the product journey, giving them context and allowing input to the product direction. Connects the day to day with the bigger picture
  • Sales tool: in some cases (e.g. B2B) can give customer confidence that there is commitment and a future vision for the thing they are buying into today

Things to watch out for, Adam warns, are the expectations set by a roadmap, the potential curve balls that occur that should change the plan (CEO, competitor, etc.) and ensuring teams remain aligned is where it can all go horribly wrong.

Expectations

  • Out of date the minute that powerpoint slide hits the printer. It is particularly out of date on longer time horizons. When stakeholders confuse your intent with a commitment you are headed for disappointment. This is why the roadmapping process is so important, and should be continuous. Aim for minimal surprises!
  • A one size fits all approach is limiting. Like any form of communication you need to tailor the message to your audience. If it’s your delivery teams you might be more specific about details and dates, if it’s marketing maybe more on the story and problems you’re solving, if it’s investors or execs maybe more on the vision and outcomes, and for a customer more focused on their specific needs
  • Everyone ‘thinks’ they understand it. The artefact is inherently high level and without proper context everyone will take away their own interpretation of what a line item is and why we’re doing it. Be as descriptive as possible but always offer the accompanying context for your roadmap

Curveballs

  • Surprises will happen… competitor movements, dependencies failing, regulatory changes, technology advancements, pet projects
  • Try to leave yourself some room to accommodate these, but more importantly keep track of what competitors are doing, watch tech announcements, stay in close contact with your stakeholders and feed facts into the roadmapping process to minimise impacts

Alignment

  • Everything on roadmap should have a reason for being there that aligns to the strategy. It’s basically a view of how you are investing the company’s resources over time so you want to keep it focused, relevant and valuable
  • Need to be aligned to the realities & constraints of your organisation or your roadmap is a work of fantasy… can the delivery team actually build this, does the technology strategy take things in a completely different direction, can marketing and sales drive the idea in market and does launch timing fit with the bigger story, are budgets and people available when you need them
  • Believing you own the roadmap. You are probably 100% accountable for it, and will be the go-to person when somebody’s heart is broken because their idea never makes it on, but the roadmap should represent a collective approach by the wider business. The product can’t win in isolation of marketing, sales, delivery, support etc.

Chris took us through some tools suggestions and the collaborative approach he takes to building a roadmap. He told his story having learnt from the painful experience of NOT doing this when he first became a product manager and shared his wise words. His preferences were for the roadmap to tell a story – so ensures that his version include where you are coming from not just where we are going. He has tried a bunch of tools too, but has made the mistake of letting the tools limit the options or that it just takes too long to update so the document beings to mould as it hasn’t been updated recently enough or the format doesn’t work for your audience.

How to get ready to collaborate on your roadmap: 

  • Establish your targets before hand, as this can be a time consuming process. This should be worked on with the stakeholders of your business (but remember… you’re defining targets, not how to get there).
  • Get your team all together in one room, and explain what your targets are and why you’re striving to achieve them. The team may also have some targets they’d like to achieve, so keep this in mind.
  • Together, start brainstorming ways to achieve these targets. It’s a good idea to have some ideas pre-prepared to get the ball rolling if the group gets stuck.
  • Properly consider the ideas that are raised by the team. If you’re only there because you feel like you have to be, and you have no intention of using their ideas, you might as well not be there.
  • Once you’ve collected the ideas, it’s time for you to go away and do your research. Try to find a way to measure the value these ideas will contribute to your goals. From here, you can begin to construct your roadmap.
  • After preparing your roadmap, show your team first. They’re the ones that are going to make your plan a reality.

Lastly, we asked Matt to give us a the devil’s advocate point of view. Is this roadmap really all worth it? Matt suggested roadmaps are a terrible idea and has so many disclaimers on his he wonders if there is any point in having one at all. The other side to this is that the roadmap can become a crutch for a lack of communication in the organsiation – “it was on the roadmap” is a common way to look like you are doing your job because it ended up on an artefact, a slide etc. but is not the case if you haven’t shared it with people and ensured the plan has been heard and understood! [editor note: Matt did me a big favour and played the devil’s advocate for the panel session, during Q&A he ‘fessed up to loving the roadmap and finding it an essential tool in his organisation].

Matt echoes Chris’ points around collaboration: the exercise of getting everyone together to develop a roadmap is a fantastic activity to perform in a company. Another benefit of the exercise is that it will highlight pain points in your organisation from an operational perspective. Typically communication issues, silo-effects, hierarchical problems and lack of alignment both vertically and horizontally. Ensuring these are addressed will significantly increase the effectiveness and engagement in your organisation.

From here we asked our 60+ product managers to get out of their chairs and have a go at roadmapping together. We asked them to think of the things they hated the most about the map, and the things they loved. Then we gave them some goals and customer feedback about a “fictitious’ food delivery service to see where the discussions would get to as a group on how to approach the process. One team did find they started with timelines… but eventually the wisdom of the group convinced the advocate for dates to switch to more general terms like now, next, later….. 

Halfway through the activity we threw a curveball at the teams, where the “CEO” pivoted and changed the focus from food to dessert delivery. Many teams were frustrated they had to go back to the drawing board (never felt that before 🙂 ) while some were able to incorporate option into their existing roadmaps with a few tweaks.

Some examples of the roadmaps made during the activity and some of the items listed in the likes and dislikes buckets:

Some of the insights from the groups:

  • make sure you convert vanity metrics to something meaningful
  • avoid any timelines on your roadmap – most commonly used groupings were now, next, later.
  • The roadmap is a useful artefact to help avoid the (random CEO) change in direction. It is evidence of what was previously agreed so should we not stick to it?
  • roadmap favourites included: alignment, customer pain points are covered, facilitates conversation
  • roadmap dislikes were: lack of context, it gets stale, change is bad!, others assume it equates to delivery

A great night thanks to Zendesk and their beautiful space. We were well taken care of by our hosts. See you next month for our May event – RSVP now.

If you missed the session – we have video content hosted on Dropbox – it is 45 minutes long.

Mapping Experiences – Session wrap-up

Thanks to Aconex, UX Melbourne and the UX Design Group of Melbourne for inviting Jim Kalbach out to Oz and pairing with us to host this event.

Jim is the author of 2 books: Designing Web Navigation and his latest Mapping Experiences. Our focus for the evening was mapping experiences.

Currently, Jim works at MURAL which helps teams design together when they are working remotely. He started out as a librarian, moved into the information architecture direction – which finally landed him in the UX space. He spent some time at Citrix leading with the design experience across the SaaS communications cloud.

 

[pullquote]”Start with the customer experience and work back to the technology, not the other way around” Steve Jobs, 1996[/pullquote]

Getting the Apple reference out of the way early :-), Jim talked about the need for the customer to come first with everything you do which will in turn create value for the business. Steve Jobs wasn’t the first to talk about this concept though as Jim shared a reference from Theodore Levitt.

[pullquote]that businesses will do better in the end if they concentrate on meeting customers’ needs rather than on selling products.” Theodore Levitt, 1960[/pullquote] In 1960, Theodore coined the term ‘Marketing Myopia’ and talked about the value comes from the customer.

With the scene set for customer focus, Jim took us through his four principles.

  1. Survival requires a reversal in business thinking: start with the experience and creates value from there.
  2. The aspiration of design should be more than “delight”. We help re-align the business perspective by visualising (actual) value.
  3. Mapping experiences leverages our design skills to become facilitators and grass roots leaders in the organisation
  4. Shift your measure of progress from generating and testing ideas to validated learning about your riskiest assumptions.

Survival requires a reversal in business thinking: start with the experience and create value from there.

Maps help with visualising value.

A beautiful example Jim used showed the process of buying a house, mapped out by Sofia Hossain. Sofia uses a circular style for her visualisations which really stands out. This style also shows the contribution of external vs internal activities

Most of the experiences a customer has will repeat themselves. There may be a long time between buying your first house til the next time but the cycle starts again in the same way each time.

An example of her work on planning events is here. .

The individual and the organisation overlap by a certain amount and that overlap is where the “exchange of value” occurs. This set of interactions or touch points is where it can all go marvelously wrong or beautifully right. If you don’t understand what these are you can only keep throwing solutions at symptoms instead of fixing the problem permanently.

This is where Alignment Diagrams become are great. They’re useful and important to help you understand these points of interaction plus help you communicate the situation to others in your organisation. Use them to help build brilliant products & to communicate what needs to be involved to resolve problems faced by the customer.

A couple of examples of different ways to do customer experience maps included mental models (Indi Young) and spatial maps (Paul Kahn), but anything that makes it visual and drives conversation falls into the group of alignment diagrams. 

The aspiration of design should be more than “delight”: We help re-align the business perspective by visualising (actual) value.

The designer needs to be a facilitator for a broader conversation in the organisation.

You are driving all the steps: 

  • Initiate
  • Investigate
  • Illustrate
  • Align
  • Envision

 An experience map by being visual and drawn together in a collaborative way becomes a “campfire that draws people in” to talk and huddle over. This metaphor is particularly powerful to remember the purpose of these efforts and a reminder that if a team is working on a map but it is hidden away in a room where no one can see it, then it isn’t doing its job.

One has to follow through with the information gathered and run experiments to prove a solution will work. It is pretty easy these days to prototype, test and thus learn. Be careful with your definition of MVP…..

Again a process to encourage Empathy, expand out to Envision, converge again as you Evaluate and then Plan experiments to learn.

Mapping experiences leverages our design skills to become facilitators and grass roots leaders in the organisation.

An organisation already has more than enough ideas. Ideas are overrated and assuming the best idea will just rise to the top is not owning the outcomes. To find the kernals within ideas that are worthy of being implemented, you need an active process. Use a hypothesis format to ensure concepts are properly tested & evaluated. The structure below starts with ‘we believe’ as it sets the stage to help remind youself that you don’t know.

We believe providing [individual, customer, user] with this [feature, solution, service] will result in this [desired outcome].We will know this when we see [measurable result].

Shift your measure of progress from generating and testing ideas to validated learning about your riskiest assumptions.

Jim’s last point is a good reminder! Often we focus on “proving out” ideas and concepts and possibly we are just adding to our confirmation bias – whereas what we really want to know is what we don’t know!

Thanks again to Aconex for putting on a fabulous event and coordinating this fantastic opportunity!

Jim’s slides:

 

RSVP for our next event on April 14th – Roadmaps: Friend or Enemy?

API Product Management & PM in general – a Googler’s perspective

We hope you can join us on Thursday March 17th when Elena Kelareva, Product Manager at Google, talks with us about product managing APIs and product management at Google. RSVP now.

From the API perspective, the session will help you evaluate if an API would benefit your product by examining the potential benefits – like driving adoption, enabling niche use cases and opening up new revenue streams. Elena will also cover product strategy for your API, give a high-level overview of API design considerations, and present several issues to watch out for, such as differences between web and native mobile APIs, dealing with authentication and abuse, and what to do if your API ends up being too popular or not popular enough.

Elena will use examples from the Google Maps APIs as well as several well known APIs for other products.

And because there’s always questions on how Google does product management, Elena will also share her experiences.

Elena Kelareva is the Product Manager for the Google Maps Web APIs, including the JavaScript Maps API, used by over 2 million websites. She has a PhD in Computer Science from the Australian National University, and has previously worked as a Software Engineer at OMC International, building software that improves safety and prevents ship groundings at some of the world’s largest cargo ports.

Thanks to Envato for hosting!!

February session: Using Google Design Sprints for Innovation

When the folks at Seek decided to explore a potential new market opportunity, they wanted to come up with ideas & test them quickly. To do so, they used a process similar to Google Ventures Design Sprints.

On Thursday Feb 18th, Product Manager Rob Alford & Lead UX Designer Rob Scherer will discuss their goals, lessons learned & what happened after the design sprint. They will also share how they modified the methodology to drive innovation, engagement & collaboration.

Join us for the 1st session of 2016 – RSVP now!

Our wonderful sponsors for the evening are Thoughtworks.

If you’d like to read about the Google Design Sprints Methodology before the session, do so at Google Ventures.

RSVP

Agile Australia is looking for Product & UX speakers

This June (2016!), Agile Australia is hosting their next conference – ‘Towards an Agile Country’.

They have put out a call for speakers – deadline of March 11th (it is never too early to start thinking!).

AND they are looking for submissions for the ‘Build the Right Product’ topic.

They thought some of us might be interested 🙂

Have a look & get in touch with them if you have any questions.

Agile Australia are especially interested in case studies. Anyone who’s been using the lean/product/biz canvas to plan & communicate and happy to share learnings should have a read of their site. And if can talk about iterating with customer feedback, they’d like to hear from you too.

For our UX folks, check the ‘Design Mindset‘ topic

Would be awesome to have our Product Anonymous folks represent at this conference! Check it out now

November event: End of year social

Why does Product Anonymous always have a ‘social’ in November?

  • Because November is our birthday – Product Anonymous is turning 5 this year!!!
  • Because part of Product Anonymous’s mandate is to get product people meeting other product people & this event gives you much more time to say hi than our usual evening events.
  • Because it means one less speaker Jen & Liz need to organise 🙂

Yes, it’s all about saying hi to people you’ve met at other Product Anon events this year or making new friends.

We don’t have a speaker but you can tell us what you’d like to hear about next year & suggest speakers.

And we need to celebrate everyone who’s attended a Product Anonymous event, helped out at an event, re-tweeted us, the companies who sponsored our events, told their friends about Product Anonymous and everything else that has helped get us to our 5th birthday! Thank you!!!

Our sponsors for this event are Versent and Level 3.

Hope to see you there!!

RSVP

Our Sponsors

Versent:
We are a young consultancy where we do our best to change the face of enterprise IT. We believe in bringing craftsmanship back to technology, building the best and most solid systems on the largest scales. We are currently hiring and interested in hearing from anyone with passion careers@versent.com.au

versent-logo

Level 3:
Level 3 is a purpose built collaborative space for events, hackathons, industry meetups, product development and desk rental in the heart of the CBD. Please enquire with us if you interested in renting the space enquiry@level3.space

Level 3 Logo

 

Wrap-up September: Product Management at Startups

This month we talked about product management at startups including how you know when you need to hire a product manager at a start-up.

Our experienced panel to help us in this discussion were:

Megan Linton – currently a Product Manager at Flippa.com but has also worked at TradeMe where scaling was definitely challenging.

Nick Kenn – is General Manager at Flippa.com, hired their first product manager and knows how hard that first recruit is.

Chris Dahl – co-founder of Nitro and currently BDM at Pin Payments. He has grown a product team at Nitro and currently works in a start-up so had lots of valuable insight to share.

Jason Kotchoff – who is a software engineer turned entrepreneur and just had some great coverage for his product StockLight. He is currently doing this all himself so had some insight into why he hasn’t hired product so far and some advice on working with product people.

When did you first recruit or encounter a product manager?

Nick opened the session talking about the first time he had to hire a Product Manager at SitePoint. He had to first understand what aspects of product management the business needed then what types of Product Manager would be attracted to a business with no formal history of the discipline.

There is a lot to consider when bringing in the discipline for the first time.

Megan was one of the first PM’s to join TradeMe and certainly found it challenging to manage the role. Product managers came in really late in the game (10+ years late) and she realised she had to be a chameleon to get things done.

It is a tough gig to be the “jack of all trades” but the master of none and manage the communication that is needed to keep so many people informed as to what is going on with product.

Chris knew he needed product people once he realised he couldn’t get everything done himself and needed help.

The key thing he looked for was culture fit. Chris had some experience making wrong hires but realised that everything except attitude can be taught. It’s better to choose the right fit than try to find a person who can do everything!

[pullquote] Everyone wants a unicorn![/pullquote]

Jason hasn’t hired a product person. His needs have usually required technical knowledge, capability to really drive innovation and the work instead of asking for or suggesting product ideas that just aren’t feasible.

With a lot of engineers already in-house, Jason feels a real clarity of technical language is critical.

What were the teething problems bringing in product?

This question tapped into the scaling perspective.

Megan experienced rapid growth at TradeMe and jumped in first on this question. Communication was difficult to manage as the company grew. Ensuring information flowed from the product team to all staff and all staff back to product was a challenge.

Nick talked about how incoming ideas are difficult to coordinate and the challenge of letting people know if they will be used, actioned or followed up on.

What is great about working at a start-up as a product manager?

You can’t hide anywhere!

What about your relationship with the founder? How do you manage this?

There were a few comments about the founder continuing to be involved with product and sometimes not always in alignment with what may have been agreed to as the current plan.

The audience joined in with some comments at this point about their experience. One topic was whether their founder was “a product person” or not. If the founder is, it can be very helpful as they understand the value of product management rather than needing it proven to them.

You certainly need to be ready to build trust with the founder.

They need to realise that you will evangelise their product as well as they do and bring a helpful impartiality to the discussion. You help bring data and user tests to the thinking as well as know how to execute on the exciting and visionary ideas.

Plus of course you just need to do whatever needs to be done to to suit that company and that product at the time!

Thanks again to Flippa for being a wonderful host and sponsor!