When your product is newly wild in the world – May event

What happens when your darling little product baby is ready for launch and support. Be it MVP or mature product, you’re letting it loose on the world and need to know how to handle what happens next.

Our speakers will discuss what happens in that launch and support timeframe plus we’ll have Q&A:

  • When is your product ready-or when are we ready to let go (ie transition from active delivery to support)
  • Handing over to a support team vs doing it ourselves
  • Looking after your customer. Or working out when / if they should just build their own team, and how.
  • Sticking to the plan (fixes, customer feedback, curveballs)
  • Sticking to the hours (work/life)
  • What if the product comes back for more? What if it doesn’t?
  • Where we failed. What we learnt.
  • Current challenges
  • Case studies: product support (4 very different models: what went well and what didn’t).

FYI, we’re not covering launch details, marketing, or metrics.

Our speakers:

Suni Stolic has over 10 years experience in delivering multiple products in web and mobile, in both Melbourne and London. While her role names changed at a speed of light, she found that the work itself changed much less. Always caring deeply about the products she worked on, passionate about understanding her users, she enjoys planning in an iterative, goal focused manner. She is great at building rapport with business teams and delivery teams, and believes in collaboration, transparency and open communication.

Suni is a product manager at Cogent and will talk through a couple of recent client experiences, from tailor made support arrangements, to the ups and downs of how things actually unfold.

Our sponsors:

The Cogent team deliver remarkable software to meet business goals, budget and timeframes of their clients. They sometimes build products for large organisations (particularly in Health and Education), other times they work with start-ups, or consult and add capabilities to existing teams. Often these client engagements are long term relationships, but sometimes they come in bursts. Most of the time they provide support to these products after delivery has finished up.

teamsquare Thanks to Teamsquare for hosting!

Teamsquare provides beautiful and collaborative workspace for Melbourne’s leading creators – freelancers, startups, designers, builders and doers. They provide amazing amenities, rock solid technology infrastructure, a strong community, regular events and a raft of services to help their members get on with what they do best. Their more than just a workplace – their a community of like minded creators.

We have a combination of open-plan workstations and private offices. Flexible month-by-month subscriptions with no lock in. Free for anybody to try for a day via http://try.teamsquare.co/

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

 

April session: Roadmaps – friend or enemy?

Are roadmaps your frenemy? There’s so much to love – and hate – about them! Let us count the ways… multiple versions for different audiences, excel/ppt, constant changes, reminding people where we are headed (& no, not that special feature for that 1 client…).

Our panelists will discuss:

  • Adam Fry – Why roadmaps are good! And why it’s bad for the product manager when the roadmap goes bad! (i.e. problems with top down directions of roadmap building)
  • Chris Duncan – How to collaboratively build your roadmap and some tools for making your roadmaps look great
  • Matt Kirkey – Why roadmaps are a terrible crux in a product managers life! You should tear them up and throw them away! (in his favourite devil’s advocate role!)

And then it’s over to attendees! We’ll divide you into groups where you’ll be creating your own roadmap.

RSVP now! for Thursday April 14th 6pm for a 6:30pm start

Our Panelists:

Adam Fry – Lead Product Manager – Sportsbet

Adam is a seasoned product management professional, having delivered and managed a variety of products and services, spanning a range of market verticals and industry sectors. He is currently Lead Product Manager at Sportsbet where he has successfully launched a number of high profile products into a highly competitive marketplace.
Prior to Sportsbet Adam led portfolios at organisations including Telstra, iiNet and VicTrack, building compelling customer value propositions, developing clear product roadmaps, implementing structured go-to-market frameworks, and managing the end to end product lifecycle.

Chris Duncan – Product Manager – carsales.com Ltd.

Chris Duncan is a passionate and pragmatic product manger, having a professional background spanning both technical and analytical roles. Over the last six years working with carsales, Chris has lead a raft of successful, high-profile products and services for which he prides himself on delivering true customer value.   Having managed initiatives right across the development lifecycle, Chris’ strength and passion is for developing solid, well communicated product strategies and roadmaps. Never shying away from a good debate, Chris is always keen to discuss all things product management.

Matthew Kirkey – Product Manager – Technology Platforms for Learning Seat

I manage 10 products across 4 streams that roughly 550 clients and 600,000 active users use. The products are in the online learning and compliance space.

I’m Canadian and my education was Computer Science, however I’m more comfortable sitting on the business/strategic side where I leverage my tech background.  I’ve worked for a large Telco in Vancouver, a start up in Georgia, Starbucks as a barista in Uni and run a consulting company for small businesses in a couple cities across Ontario.  I’ve covered business intelligence, IT project management, business analysis, process engineering and somehow managed to setup a renegade data warehouse in a telephone exchange building somewhere in outer Calgary.

For fun, I run a curated weekly event newsletter, a semi-regular pub crawl and am writing a book about craft beer (ideas and suggestions welcome).

RSVP

Mapping Experiences with Jim Kalbach – Special Event!

Jim Kalbach, author of Mapping Experiences is in town for a couple workshops on experience mapping and UX strategy.
Mapping Experiences

With the help of Aconex and UX Design Group of Melbourne, we are lucky enough to have Jim for a special Product Anon on Thursday April 7th. Jim will be talking about mapping experiences and how to create value using customer journeys, blueprints & diagrams.

RSVP now!

To attend Jim Kalbach’s workshops:

• The Mapping experiences workshop is on the 9th of April.  Details & Tickets.

• On the 11th of April, Jim will focus on UX strategy. Grab your tickets now.

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

    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

    End of year wrap!

    It has been a fabulous 2015 – with some great sessions and attendance this year, lots of new venues, our biggest Product Camp ever and our first product management conference ever!

    We wrapped up the year with drinks and chats and some birthday singing at Level3space – which had beautiful views for the evening and good conversations was had.

    image5

    image1

     

    Happy birthday!

     

    Generous serves of pizza and beer kept the crew happy and we thank our hosts for their generosity. Check them out if you need a space for an offsite, a function or anything else that you might think of.

    image3

    This is our last event for the year – we start up again in February. Join us on Meetup to ensure you get notified as soon as we announce our topic and location for 2016.

    image6

    Thanks everyone for contributing to such a fabulous 2015 🙂