Tips for Better Presentations- Product Camp special event

With Product Camp coming up quickly (RSVP now for August 20th), we wanted to run a session to help people who were thinking about doing a presentation or leading a topic at camp – and who better to supply us with tips than Adrienne Tan of Brainmates?

Adrienne was instrumental in starting product camps in both Sydney & Melbourne and has been a part of lots & lots of camp talks. She always does a great job & makes it look so easy! (Even though she told us she used to be bad at presenting…).

When Adrienne has to put together a presentation, one of things she does is check out what the experts are saying. On tips for better presentations, the experts talk about practicing, speaking slowly, not reading and more (there’s a list in the slide deck below).

During the evening, we talked about:

  • standing vs sitting (sitting not recommended)
  • even if it is a report you need to present, don’t read it & don’t present it as a report
  • get the audience excited about the topic & you should be excited too (that energy will be contagious)
  • connect with your audience
  • when you start thinking about your presentation, opening powerpoint should not be the 1st thing you do

One of the most important things is to think about what you want the audience to leave with – a piece of information, a need to take action, etc.

She also talked about the structure of the presentation & gave a typical example but recommended reviewing the structure Nancy Duarte talks about in her book, Resonate.

Adrienne also talked about the visual part of your slides. She will sometimes create her own images (slide 5 for example) or use unsplash.

What Adrienne really stressed was each of us need to find our own presentation style. Her style includes working out the angle & planning in her head before writing it out plus including a trigger on each slide to remind herself what she wanted to say (more in her slides below).

She knows some people who write out their entire talk word for word & practice.

But it’s about finding what works for you.

Since this was an event for Product Camp, we answered lots of questions about the day. Here’s just a taste:

What sort of talks are given?
In the past we had people present (both with or without slides), say they wanted to discuss ‘x topic’ or an issue they are facing and conduct a round table discussion, have interactive sessions where we played a game or did a mass JTBD interview, panel Q&A, etc. We have more info about session types on the Product Camp website.

What topics are of interest to the group?
Everything from roadmaps to stakeholder management to getting a job to working with other teams to…. everything.

Have a look at the session summaries from Product Camp Melbourne 2015

Do I really know enough to give a talk?
No one knows EVERYTHING so yes, you probably do have enough information to talk about something but it’s not only facts we’re interested… it’s your experience. Giving a talk might be leading a discussion about something you’re passionate about or something you want to know more about. You can absolutely say ‘I’m interested in X. I don’t know much but if there’s others who are willing to share, this will be a great conversation’.

What is camp really like?
Check out photos from the last 2 years to see what the day is like.

Thank you level3 for hosting us and Adrienne for the wonderful talk!!! Adrienne has kindly offered more help to those who want to present at camp. If you’re interested in presenting and want to run an idea or content past Adrienne, you can get in touch with her at actan at brainmates.com

Managing Product Managers – June wrap-up

This month’s topic was managing product managers.

Often Product Anonymous events cover topics to help make you be a better product manager – like roadmaps – but we also need to focus on the the people skills. This month we asked a couple managers of product managers what they do to ensure high performance & keep their people motivated.

Layla Foord has over 20 years experience managing teams of product people. Fiona Moreton has over 15 years as a team manager with background in customer management & sales teams and has been managing product managers for the last 3 years.

How do you structure coaching and mentoring of your people?

Fiona is a real believer in the 70:20:10 management rule (as is PageUp). This focuses very much on on-the-job training.  She is involved in providing personal feedback to her people which is very individualised feedback. It needs to take into account where each person is on their journey plus experience in product management.

Layla has managed many people and concurred with what Fiona described as on-the-job observation and personal tailoring of the approach.

She also talked about understanding where your people are on the spectrum – product management is a range of skills and needs. You need to understand each person’s super powers and ensure they are using and showcasing them. Layla described how sometimes her people didn’t want to use their super powers as they saw them as skills to avoid using – but she finds this leads to dissatisfaction in the person and discontentment at work. 

How do you guide your product people through the pull of the technical owner role?

Fiona’s take: PageUp has just decided to rearrange things. They split the roles and will have product owners and product strategy managers. This allows for the clear division of roles but of course they will need to work through how to share and communicate between the two groups.

Layla: talked about it being a range that they are still figuring out. It will keep changing. Right now she guides people towards their strengths. If their strength is working deeply with the tech team, that would be supported. Layla did make a point about the danger of micro-managing the team… if the product person isn’t providing the necessary information for the team to make decisions on their own, that product person is a control freak. You are there to provide a vision, not dictate a back-log.

Layla encourages her people to drop the ego. If you’re only interested in getting your ideas onto the product then you are doomed! Every product manager needs to be ready to accept ideas that come from anywhere and ensure general principles of the product are understood so everyone can contribute.

What does a development path look like?

Layla: Some people get very interested in the detail (technical or otherwise) and she thinks it’s important to remind them to look up (she did quite a good animation of lifting up her chin! 🙂 You need to see beyond the immediate moment (the firefighting).

When they are able or willing to look to that second horizon then are ready to move to more senior roles and the most senior are casting out to horizon three.

Fiona: Knowing when someone is ready for the next step is a combination of time in the role, aptitude and attitude. The way in which they engage with other stakeholders in the business -beyond their own team – are other signs they are ready for those next steps. And there are other ways to keep a person challenged than just the title, it can be about expanding the responsibility of work they are looking after.

How do you decide to carve up product responsibility (say if you have a portfolio of products?)

Fiona had to leave before these last 2 questions.

Layla is a big believer in ensuring the product person has an end to end view. Figuring out how to slice and dice is still a challenging question depending on the product and organisation but she would always attempt to ensure the view is breadth rather than depth.

Should product people be assessed on hard metrics? Aligned with company metrics?

Layla: Honestly? no. Your strength of skills is in areas that are subjective and can’t be measured.

One comment from the audience on this question said it’s tough to align on the company metrics as often they are too short-sighted. A product person is making efforts or work that won’t have an impact on company metrics until 2 years or more down the track.

Thank you to Layla and Fiona for their forthrightness, honesty and humour for this session.

Thanks again to PageUp people for hosting us! Great space and support for our event.

Join us for our two events in July – a prep session for speakers for ProductCamp and for a chat about financial skills in product mgmt.

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.

 

“Start with the customer experience and work back to the technology, not the other way around” Steve Jobs, 1996

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.

that businesses will do better in the end if they concentrate on meeting customers’ needs rather than on selling products.” Theodore Levitt, 1960

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 with Elena Kelareva – Wrap-up March 2016

Our event this month had the wonderful Elena Kelareva, Product Manager at Google, talk with us about API product management and product management at Google. Elena is currently the product manager for the web maps APIs – and there is a lot to that group of API’s!

Having an API can aid your company in a number of ways. It can:

  • Allow you to build usage
  • Be a revenue model (which the maps API is)
  • Allow for the extension of ideas beyond what you may first imagine with the core product

People can use API services to serve a niche market that otherwise wouldn’t be possible. For example, birdwatchers can use the Maps API to build out sites that Google wouldn’t directly build.

API Product Management

Elena had three main points when thinking about managing your API. She provided some call-outs to consider before embarking on building an API and ensuring your intention is known before you get started.

When thinking about managing an API vs a 1st party product, Elena’s 3 main points are:

  1. You have an extra stakeholder to work with! Instead of just company and end users, you now have developers as a key party to consider.
  2. API’s are harder to change
  3. Management of the applications of the API

Developers as a stakeholder

Developers are critical to the success of your API. They can extend your product in ways you will never think of and will add features to their product that only your API makes possible.

Ensure you API strategy is aligned with the needs of the developers – be clear about the core user base and their business strategy including your SOAs.

APIs are really hard to change

Changing an API is like trying to redirect the Titanic! Elena shared some war stories to illustrate why.

Because entire businesses have built their sites on the Google map API, changes become hard as the API is so integral to these sites. When the Maps API was ready to update to v3, they gave sites 3 years to transition to the new API. As the deadline approached, they realised many users had not done the work so they extended the deadline by 6 months. Still, people didn’t switch so they started reaching out to individual sites to see how essential the API was – could they just turn off v2? Turns out people could actually die if v2 didn’t function which lead to Google building a ‘shim’ to do the translation from v2 to v3.

Elena also talked about when Google decided to charge for the use of the API. This happened in the early days, before Elena was PM, but the ramifications of such a switch in strategy is something she is very much aware of. Even though the charging model only impacted the top 1% of users (big sites/organisations who had large usage, as the model was based on usage). Certainly the perception was a painful lesson for any product manager to be more considerate of what your long term goal might be for a revenue model and tread carefully when starting out “free”.

Getting ready for my first @product_anon #product_anon with #elenaKelareva from #google

A photo posted by Rita Arrigo (@ritaarrigo) on

Pros and cons of the possible applications of your API

Day in & day out, Elena is inspired by the different ways the APIs are used. This is a fabulous aspect of being an API product manager & thinks that inspiration is one of the best perks of looking after APIs. There are so many developers out there looking to try great new things in creative ways and using these tools to save time.

Some of her favourite examples are disaster related initiatives such as those created during Black Saturday and flood maps that highlight the impact of global warming. These helped show people where the emergency was happening and helped people let families know they were in safe places. Another local example was infoxchange which is helping homeless people find services.

The downside to creativity and innovation is those who use the tools for not such great applications. Keeping an on the inadvertent as well as the deliberate misuse requires constant monitoring. The careful drafting of terms is an important part of the role to ensure you have something to fall back on to block those users or manage their actions to prevent harm to the rest of the community of users + your company.

Thanks to Elena for sharing some very practical tips to a highly technical product service!

What’s it like to work at Google as a PM?

The moment we had all been waiting for – what’s it really like to work at Google?

Outside of the more obvious perks that are talked about, the hiring process includes hiring for niceness. Building a great culture is often talked about across the blogosphere but such a simple rule is so much easier to follow.

Elena talked about how great it was, having interacted with so many people, that she had yet to run into anyone not nice to work with. The company also supports this continued application by encouraging or allowing staff to award a colleague with a bonus of $500 when they do something above and beyond for another colleague. That helps create a culture where people are very willing to help each other out. The behavior is also encouraged through performance evaluation, which is less aligned to product success metrics and instead tied to 360 feedback and collaboration with colleagues.   

The other insight was about how much room a product manager at Google has to shape their role and product rather than receiving much top down directive. Elena was mildly surprised when she started at Google (her first PM role) that she was given 3 page document to start work. The document was mostly a list of names of who she should talk to instead of a list of ‘things to do’.

In some ways, this is so obvious that I am surprised more of us don’t just state that as the approach. A key part of being a PM is to listen and understand how things tie together and who does what. Only once you have understood that space can you possibly form and contribute opinions in to what to do next. That fact that Google openly acknowledges this, sends their PM’s off to do that and gives them time to get to that stage without dictating is fabulous. However, as a PM on her first day on the job, Elena did find it a little intimidating!

Thanks again to Envato for hosting us this St Pat’s day and please join us for our next events. We have two for April – a special event with Jim Kalbach on Mapping Experiences and our main event for the month is all about the wonderful topic of Roadmaps: friend or enemy!?!

 

February wrap: using Google design sprints for innovation

Seek’s Rob Scherer (Lead UX, Hirer products) and Rob Alford (Product manager, New products) came to talk to us about their use of Google Venture design sprints.

They were looking to come up with a completely new product idea and wanted to challenge themselves & the organisation. The guys did a great job of explaining the process without telling us what the market or product is – they are currently building the product & we can look forward to a very exciting launch I am sure.

Before jumping into the design sprint, they worked with the person who would facilitate the session and tweaked the Google process to suit them. One of the main reasons for trying this approach was to ensure coverage from multiple functions of the business with an approach that forces (encourages!) collaboration and allows everyone to contribute. People from various departments are locked in a room for a week and aren’t allowed to leave…. (well, maybe not that strict! 🙂 )

As Google describes it: “We shortcut the usual endless-debate cycle and compress months of time into a single week. Instead of waiting to launch a minimal product to understand if an idea is any good, teams get great data from a prototype. The sprint gives these companies a superpower. The ability to build and test nearly any idea in just 40 hours.

 

So what did Seek do differently to the Google approach:

Seek wanted to use the sprint methodology but were keen to make a few modifications to incorporate their own experiences to the process.

The Team

Google recommends 4-8 people for design sprint. Seek set up a bigger team of 12 people which allowed them to have a broad representation of the areas (development, marketing, strategy, BA, etc) needed to explore this space. While a senior person was in the room on the first day to help set the stage… that’s the only day! Having no senior team members helped do away with group think as no one was waiting for the senior person in the room to comment. They broke the 12 down into smaller groups of 3 for the sketching.

Time & Steps

The Google approach, takes a team of 4-8 people and spend one day for each of these steps:

Unpack -> Sketch -> Decide -> Prototype -> Test.

They also decided to add a few more steps to bring it to 7 days:

Unpack -> Build Empathy -> Sketch + test -> Sketch + test -> Decide -> Prototype -> Test.

Seek added ‘Build Empathy’ as a request from the UX team. The product guys weren’t so sure it would be useful, they were a little skeptical before doing it, but after trying it they were converted. With such a large group consisting of some people who were new to this type of work, having a day spent on empathy helped to ensure everyone’s mindset was in the right place for thinking about the customer. Seek also added more time to the Sketching section. They wanted to be able to sketch in the morning and then test those ideas in front of customers that afternoon. By doing this 2 days in a row, they had a lot of items validated before getting into the Decision day and presenting to the execs. They feel having the extra time to sketch/test worked really well for them.

Pre-planning & getting outside help

Before the design sprint even started they did a few things to help organise:

  • Booked a dedicated space where they could keep the entire week’s sketches on the wall. They ended up having so much they took over the wall outside the meeting room. Seeing all the work they created over the week was very motivating to the team.
  • Booked the people they’d be showing their sketches too (assisted by their usual research folks)
  • Booked the meeting where they’d present to stakeholders
  • Organised an external facilitator
  • Organised homework for the team (see below for details)

 

What is involved in doing the design sprint?

There is a tonne to do to get ready for the sprint and if you look over the resources you will see that these are just a couple of tips to be aware of where to put emphasis and not skip!

  1. Homework – Before the design sprint started, each member of team had to do their homework. Each person was given a competitor to research and everyone was asked to think about something that inspired them. At the start of the sprint they needed to talk for 2 minutes on each piece of their homework. NO POWERPOINT! The competitor research was kept intentionally light.. what they liked, disliked, etc. Just insight, observation and sharing with everyone else. This was a great technique for divide and conquer. The inspiration step was also a great tool for encouraging people to remain open-minded and positive about what they could do, instead of possibly limiting themselves to iterating only on what was out there already.
  2. Learn to draw exercise – this was an amazing insight from the evening. Everyone was “taught” how to draw including the UX’ers. What this actually meant was that everyone was shown how to draw in a consistent manner so that ideas could be judged equally, not on the skill of the sketcher. Vedran has written up the details on Medium but bascially: use a thin liner pen to draw the outline then a sharpie to accentuate any aspects, a yellow highlighter to draw attention and one grey pen to indicate background/what to ignore. From here, when ideas from different people were combined, the customer could not tell the difference between the sketches and much time was saved by not having to redraw.
  3. Everyone facilitates – to ensure inclusion everyone had a go at facilitating as unseasoned researchers will tend to present more than facilitate but for best results, this should be seen as facilitating user research rather than presenting designs to users.
  4. Everyone takes notes – the intensity of the time-boxing might assume everyone pays attention but everyone was asked to take notes to avoid drifting off, but to ensure people remained engaged. It also helped with adding insights as people took things down and then had to repeat back what they had heard.
  5. Guerilla testing – go to users unannounced and then try out your idea and you will get some very different responses. Rob & Rob noted the big difference in commentary you’ll receive between bringing customers into your office vs going to their environment where they feel comfortable. You’ll get more critical & real feedback when you are in their environment (plus they want to help you solve the problem & will give you ideas).

Key ingredients to success

  1. Having time constraints – This was the most important factor for them & the faciliator was great in moving them along. Enforcing the time constraints meant they stayed focused, had something to show customers and were ready to present to the execs.
  2. Right people – this means the right representation from the organisation for the area you looking to be innovative in but also avoiding any senior execs that might inadvertently provide bias too early.
  3. Keep it visual – have everything on the wall where all can see it, communicate with images, drawing instead of talking.
  4. Use an external facilitator – keeps things neutral, allows the entire team to contribute to the process instead of worrying about the process, can tell people to shut up and get working, which again might be a bit hard for one of the team.

Results (& Would they do it again?)

Yes, Seek have tried the methodology again since they got such a great result the 1st time. The team got a business case up in just a few weeks after the sprint, and the approval process was smoother due to the excitement the sprint had created. The team have been building the product since.

Rob A wasn’t convinced you could use it for every project, partly because it remains hard to convince an organisation to give up people for a week and partly because not every product needs such a methodology. On the other hand, participants of the sprint have gone on to use it in their area as they got so much out it. Aspects of the sessions have also been cherry-picked out as proving to be really helpful tools – such as the drawing component and have been applied in isolation.

It was great to get to hear from an organisation that has used the methodology with such success but also shared with honesty the tough aspects of running it. The intensity is clearly not for the faint-hearted and may well be a stronger reason for not re-using more frequently. As the team that were involved in the sprint went back to their day jobs or moved on to build the prototype into product their focus has also shifted for now. However, any company looking to break themselves out of their norms and product innovation from within should consider using this approach.

Further Resources:

  • The presentation
  • Google Design Sprint prep in detail
  • Vedran’s article on drawing the same way + his perspective on the experience
  • Thanks again to ThoughtWorks for hosting + pizza & to Moondog Brewing for providing such tasty beverages.

    RSVP for the next session in March as we talk more Google topics (API product management & being a product manager at Google)!

    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!!

    October wrap: How to transform and optimise experiences

    Our October event was all about transforming and optimising experiences for our users. – and both talks also included a healthy dose of tips for communicating value and change to your organisations.

    We had two great speakers to delve into this topic – Kirsten Mann, Director for Global Design & Experience at Aconex and Leisa Reichelt, Head of Service Design and User Research at the Digital Transformation Office. Leisa brought quite a lot of insight having spent a number of years with the UK Government at the Government Digital Service (GOV.UK) and is now here to help the Australian government similarly improve their sites.

    IMG_0440

    Kirsten started the evening telling us how Aconex brought down business costs by building a great support site.

    It all started with the data – 4000 abandoned calls each month! The UX team thought this would be an easy thing to fix which could show measurable ROI – not always an easy relationship to draw. Aconex spends a lot of time & money on face-to-face training and travel so the UX team developed a vision statement to get rid of the cost heavy training approach …if they could provide a end-to-end online support system.

    The team tried different ideas & prototypes – including some with aussie humour which didn’t translate across all cultures. 😉 After trial & error they came up with a new version of the support & training site. They saw a reduced cost as the need for F2F training was dramatically reduced.

    The Aconex UX team had a great win by showing the organisation it could have real ROI impact. Being able to show this & have a win like this early will smooth the road for future plans – and save costs.

    Part of the UX success at Aconex goes back to where UX fits into the organisational structure. Kirsten used a great metaphor of the 3 legged chair – you lose a leg and things will fall over! These legs consist of product management, tech and UX.

     

    IMG_0443

    Our other special guest for the evening, Leisa Reichelt, has recently returned to Australia after a long time in the UK working at Government Digital Service (GOV.UK). Her focus is to transform public services with user centred service design. Why? Because in any 4 week period more than 1 in 8 Aussies, over 14, will use a government website. And 55% hit problems completing what they came to do.

    I’m trying to stop people from crying

    Leisa took us though 4 learnings for user design at a gov’t organisation but the 4 are great for product managers as well.

    1. show don’t tell
    2. ask for less, simplify
    3. change the language
    4. plan to do more comms

    show don’t tell

    The show don’t tell principle is rather brilliant. In the product design world we talk ad nauseam about prototypes but what Leisa kindly reminded us about is the meetings we have telling people stuff are such a waste of time. We could be showing them something and having a discussion about what’s next instead of throwing out the “we’ve done that before” types of blockers.

    IMG_0895

    Ask for less and simplify

    This is a clever organisational navigation tip. We often despair when we cannot get the 1M we need for the whole project or the 3 resources we absolutely need to do all the projects. That’s when we give up and get nothing.

    Why not ask for (& receive!) 20K, do something and then ask for more?!? Ask for 1 resource (or half a one) & use them brilliantly. Once you have something to show as a result of that resource, THEN ask for more.

    Put a number in the request – don’t ask for lots of people or money as again this tends to leads to a no answer.

    The approach of being specific with a figure led to some very clear guidelines on ensuring your purpose states what you are doing with measurable details. so you can show you are doing, but also so it is very clear how to get started!, how to keep going and prove you have used the resources you asked for.

    Language is the medium through which culture is enacted – Gill Ereaut

    Change the language

    This was an indulgently awesome moment as it is something I have been talking about at my companies for awhile now and appreciated Leisa being so forthright on the subject…

    Any product manager will recognise this situation: that annoying moment when the nickname for a product suddenly becomes the language of the company & when you finally “announce” the real product name it is too late since it will forever be known as the nickname. < SIGH >

    Leisa’s point is that language permeates even deeper than that. Her examples touched on the difference between calling yourself UX or UCD & then further on trying to put a nice interface over really terrible policy. If you want to get a different outcome you need to change the language.

    IMG_0908

    Plan to do more comms

    One cannot forget the need to communicate, communicate, communicate. When you think you said it enough, say it again!

    You are not finished communicating until you are being told the story back to you as if it is fact. Make sure your message is clear (is it clear YET?) 🙂

    She closed out the section stating that there isn’t any point doing the work if you aren’t going to share it.

    So much wisdom from both these ladies on this wonderful night!!

    Thanks to Aconex for their once again fantabulous hosting. A special thanks to Kirsten for pulling it all together! And awesome coordination/promotion with UX Melbourne and the UX Design Group of Melbourne! Let’s do it again guys!

    Our last event for the year is on the 26th of November so please join us to reflect on the year that was, share ideas for next year and just mingle and network. No formal talks this session, just conversation, and a drink to wish Product Anonymous happy 5th birthday.

    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!

    Everyone wants a unicorn!

    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!