Monthly Archives: April 2016

Roadmaps: Your Friend or Enemy? Session Wrap-up

Posted on by
Reply

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.

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

Posted on by
Reply

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

Posted on by
Reply

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

Posted on by
Reply

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