September Summary: Chatbots & Voice

At our September evening, we had 5(!) folks talk about using chatbots and voice activated products within your product.

Keith Swann began the evening with a bit of background on chatbots. Keith is a Lead Consultant at Elabor8 and while he was at Sensis / Yellow Pages he was able to work on bots. Daniel Galindo, the lead ontologist at Sensis, joined him in the presentation to share with us some of the experiments they had tried with working with natural language requests.

Did you know the 1st chatbot was ‘born’ at MIT in 1966? Eliza was a psychologist you could chat with.

In 2005, IKEA introduced Anna which was another big leap for the use of chatbots.

Keith giving us some robot history #prodanon

A post shared by Product Anonymous (@product_anon) on

Chatbots come in handy for sharing information with people. A good example is to collect information via chatbot while the customer human is awaiting the customer service human. This can decrease the amount of human time involved in the call. Sensis used API.AI and Python.AI for their business search in this manner.

Keith also talked about how chatbots can be easy to create – but it’s not easy to make it work correctly. It’s also not a set & forget product as you need to continue to manage user expectations. One of those expectations that’s the hardest to get right is the natural language of the chatbot. Getting this right is important as it impacts on people’s engagement with the service.

Jen Leibhart & Stuart Hill from Australia Post talked about developing a chatbot as an experiment & how to approach giving your chatbot a personality.

The team used an internal hackathon as the opportunity to experiment. They wanted to drive awareness and traffic to a MVP product they were working on and the primary audience for the MVP were digital folks who used Slack on a regular basis so a Slackbot was a given.

At the beginning of the hackathon they had grand ideas of having both a Slackbot and a bot in Facebook Messenger. They wanted their bots to have great personality and do x,y AND z. That’s a lot of work for a 1.5 days so they kept functionality x and dropped y & z. 🙂

A few weeks after the hackathon they focused on the Slackbot, put in a little more effort and launched the bot across multiple slack workspaces. Six months after that hackathon, the Slackbot still has limited functionality but does indeed drive traffic.

The next experiment is to see how conversation increases that engagement. Stu was looking at how to build conversation with the bot. This includes thinking about both tone of voice and attitude. Just as you’d think about voice when building a brand or website, you need to translate that to the bot.

Stu thinks of it like one of those ‘choose your own adventure’ games. You need to think through the conversation a human will be having with a bot. To help give a bot more personality and be useful, Stu has been creating conversation maps to think thru the variety of answers the bot needs to provide. While it’s great fun to teach the bot to tell jokes, you need to make sure it always leads back to delivering value.

Advice from Jen & Stu if you’re creating a bot:

  • As with any channel, will it reach your target market? Is your audience using FB or Slack or something else?
  • Focus on 1 task that can be done well. You can expand beyond 1 after that’s working well.
  • Use conversation maps to ensure the bot delivers the information required.
  • Give it a go, learn & experiment!!!

How to build your Chatbots personality #prodanon

A post shared by Product Anonymous (@product_anon) on

Srinjoy De works at RACV in their New Products team. The team are currently working to bring intelligent tech solutions for the home. Previously he was at Catapult Sports, a leader in wearable athlete analytics for elite athletes.

Srinjoy talked about the possibilities of using voice technology to improve customer experience. Washing machines, fridges, cars and other machines are now loaded with Amazon’s Alexa. With Google Home recently launching in Australia, we’ll start seeing more and more voice products.

At RACV, they are running a trial using Google Home in some resorts. When you enter your room, there’s a Google Home which you can ask about the local weather or traffic or other holiday related queries. Using the device to play music is popular though in the future it could become a personal concierge (by controlling the lights or more). Since the device is so new to the market, we wondered what the adoption & onboarding was like during the pilot – Srinjoy said people adopt the technology quickly.

Srinjoy on a Google home experiment #prodanon

A post shared by Product Anonymous (@product_anon) on

Thanks to everyone for coming along last night! Fantastic eve of new tech learnings. Summary will be on blog soon #prodanon

A post shared by Product Anonymous (@product_anon) on

Thank you to Fiona Knight for volunteering on the night & helping to pull this blog post together!

Big thanks to MelbourneIT for hosting us!

July wrap-up: You can prototype ANYTHING!

Prototyping – typically we digital folk think of going from some sketches to maybe a clickable prototype then to a fleshed out, semi-built format which we can test on.

But what if your product wasn’t digital? And even with digital, can you do something different?

Jes Simson is a product manager of greeting cards. Not digital but paper. And she loves to prototype. Having a physical product reminds us of the importance of risk. When you’re producing 1,000 products a year with an expensive production cycle, you want to test & validate along the development cycle.

In the grand scheme of things, there’s a lot of similarities between digital and physical. Start by looking at your insights & research. Prototype and soft launch with 1 item until you’re ready to go bigger and branch out.

Jes says a prototype is just a question embodied – and first you need to decide what will kill it?

Brainstorm your assumptions in each category (desirability, feasibility, viability). Try to surface every assumption you have & use tools like a risk template in order to get as many as possible.

After you’ve discovered your assumptions – rank them! Take the riskiest assumption & decide what your questions are. Find the cheapest way to test this. ‘Cheap’ could be money, time or the people involved.

Some of the ways Simson tests assumptions are taking a short period of time to create a mood board and see if it resonates with card buyers. This is quick to produce & quick to get feedback.

One ‘fabulous’ example of a prototype Jes shared was using a post-it note to illustrate you could fit the word ‘fabulous’ on a card – that it wasn’t too many characters and you could stylize it in such a small space. Point made & progress continued.

Ask yourself who’s in the best position to answer these questions? You might not be able to access them depending on budget or time so … who’s available?

Be willing to throw things away, to iterate quickly and focus on the getting to no.

Jes also thinks of a prototype as a communication tool. A tool which needs to change based on who your audience is. Your design team may need 1 type of prototype while sales or finance will probably need another. Keep those team specific prototypes with the team… don’t show your CEO the grey lead sketch 😉

To help us understand you can prototype ANYTHING, Jes gave us aluminum foil and a challenge. This then became the most photogenic Product Anonymous session EVER.

A big thank you to Jes for a great talk and to Sportsbet for hosting us!
Once again, a huge thank you to Fiona Knight for taking these notes!

Directing the Product – June Wrap-up

Our June session brought together a panel who lead a team of product managers – as well as a product. It was a fantastic evening covering a wide range of topics, from cats and racehorses to ***holes.

We were joined by Susan Teschner from 99designs, Luke Bongiorno from Nintex and Rachel Morley from REA.

Once again, a huge thank you to Fiona Knight for taking these notes!

Product people always have diverse backgrounds – our panelists included. Susan has a political science degree and accidentally fell into tech via project management. Rachel was studying Law & Arts degrees before getting enticed into this new thing called an ‘intranet’. Luke started in tech but realised it wasn’t for him. Fortunately he was in a company with opportunities that lead to product management.

How do you nurture product management teams? What do they need?

Rachel, Susan & Luke all mentioned that managing product folks can be challenging since PM requires such a broad spectrum of skills & interests. Susan & Rachel talked about how a great product team is made of people from across that spectrum but that diversity is part of the challenge of managing them and helping each individual to grow in their career. Luke looks at how they can build their skills to be more holistic.

Ensuring the team of product folks are working consistently across the business was a theme both Luke & Rachel raised. That includes making sure they’re in sync with the company’s vision

What’s it really like managing product folk? Rachel finds it’s sometimes like looking after a bunch of cats that scatter when they see you. While Luke compared us to managing racehorses who are strong willed leaders with a range of skills and experience.

Tips? Show them respect. Nurture the diversity. Encouraging communication with their peers and other teams.

this evening hosted by Nintex

A post shared by Product Anonymous (@product_anon) on

What does the business expect of the product management team? What do you ask of your team?
As with much in product management… it depends!

REA is mature in understanding what it wants from a product management team but at previous roles Rachel needed to champion the value of a product management team. These days she focuses on creating the best opportunities for work relationships, establishing those relationships between people & creating harmony.

Luke is helping his team understand their boundaries & show them how to have space to do their job.

Susan asks for a focus on the goals. Doing the impossible by being down in the detail and up at 30,000 ft keeping an eye on the end game. We have to learn to live with some fires. The incredible attention to detail and passion for delivering great products is the very thing that can also distract us.

Cue the conversation about product people fighting fires versus keeping an eye on the long game.

Going from product manager to product director – what is it like? Are you still working on the product?

Luke is relatively new to the role and learning – while still influencing all of the products. Rachel added that doing actual work on the product depends on the size of the team. If you have more than 8 people, you’re in a true leadership role & need to love helping people rather than the products. Susan thinks it can differ depending on how you define success and what it means to you. Being successful doesn’t always have to mean managing people so you should decide what is meaningful to you. Liz brought up the difference between rock stars & superstars which come from the Radical Candor framework – TED talk or check out the book and site.

How do you keep the alignment with product managers and their development teams?

Lots of consensus on making sure there is a product vision across all teams, making sure there’s clear alignment on the objectives and measures on how they will achieve the objectives.
Rachel believes clear goals are the way for teams to be autonomous and self sufficient.

Product managers have broad & different skills sets. What are the detailed or deep skills product managers need?

Susan — There are lots of different kinds of products that need different kinds of product managers. We need the good old ’T’ person. Good coverage of the basics and deep knowledge of something — UX, data, growth, whatever they’re strong in and passionate about.

Rachel – Always talks about goals. Rachel gives them time to look at their goals & sends the prioritisation list to the executive team. Being able to focus on the goal and prioritize the things that will bring you closer to the goal is important. Being busy and getting lost in the detail can be a distraction.

Luke – Something to watch for is product managers who work on what they’re good at and avoiding goals that might not play to their strengths. Bring the product folk together to talk through this – make sure the team talks about strategy and doesn’t only talk about the tactical.

What are the top three things that makes a good product manager?
Rachel – Start at hiring and look for attitude, aptitude and empathy. If someone is committed and enthusiastic, that’s a great start!

Susan – Smarts/ intellectual horsepower, humility (realise there is the likelihood of working for no individual credit but all reflecting back on the team), judgement/decision making/ instinct

Luke – Switched on/ thinking ahead/ inquisitive, passionate/ excited about releasing products, emotional resilience

Thanks again to Nintex for hosting!

See you next month at Sportsbet where we will be talking Prototyping. RSVP now.

May wrap-up: Working with User Research

WOW! What a fantastic evening! If you’re interested in user research, I hope you were there! Otherwise read on for the summary.

Big thanks to Fiona Knight, one of our volunteers, for taking great notes!

Using Experience Sampling for Rapid Insights into User Needs

George Cockerill started the evening off with a discussion about how his team approached gathering user research in a project building a smart assistant for students at Deakin University.

The team decided to use the Experience Sampling method. Other methods like interviews & diary studies have participants recall their past whereas experience sampling gave them access to detailed immediate needs.

With experience sampling, you ask short, easy to answer questions throughout the day. For this project, the same two questions were sent to participants eight times a day over a week. Occasionally the team would add an optional question. Experience sampling allowed the team to get to very recent needs & the student’s behaviour.

To collect the data, George used PACO, a free app that builds experiments quickly. It’s great for experience sampling and since it’s an app on participants’ phones they can take photos to include with their answers.

Tips for success

  • Get maximum value for the method – be clear about the research goal
  • Don’t rush, plan meticulously & plan to be flexible. Plan even when you need to go fast (it actually helps you move quickly!)
  • It’s a complex set up – test it; test your questions and mechanics
  • Get the most from people – recruit and onboard carefully. Establish how much data points you need to help determine how many participants you should have. When you screen them, ask questions along the lines of what you’ll be asking during the research. If they can’t answer in the screener, they probably won’t provide good data during the research. Your onboarding needs to have very clear instructions. George made a video to help explain the app and expectations of the participant (including what they needed to do /when they’d get paid).
  • Monitor it! Experience sampling is not a ‘set it & forget it’ method. You can be encouraging to the participants or ask them to tell you more about a specific thing. It’s awesome if you can instill a shared purpose of what’s going to happen with the data they provide.
  • Use the data to help refine the problem. Start finding themes, create categories, map answers to categories to find patterns, map data to graphs and examine categories to fine tune them. Look for trends. With participants using their phones, images will pick up detail the users might not think to say like how they solve their problems, their hacks, etc. You can combine the data with other research (both qual & quant). For this project, George combined experience sampling, resonance testing, journey maps from user interviews and ‘day in life’ models.

Currently the student smart assistant is in a pilot with a set of students. We’re looking forward to hearing how it goes!

George Cockerill on experience sampling #prodanon

A post shared by Product Anonymous (@product_anon) on

George recommended two excellent references that he found helpful in planning and running the research:

Why is marathon running important when introducing user research to an organisation?

Electronic Arts operates 8 research labs across 4 countries but it’s still early days for the games industry to embrace user research. In the APAC region, Kostas Kazakosis the 1st UX researcher at EA and thus needed to help communicate the value & importance of UX research.

Using ‘The Reflective Practioner‘ by Donald A Schon, Kostas reflected on his journey as a marathon runner and introducing UX research to a company – both ongoing!

Kostas finds there’s 8 stages to long distance running

  • Excitement where anything is possible! The organisation has no prior exposure to formalised UX research.
  • Denial when doubt starts to creep in. Here Kostas realised he didn’t know much about the FireMonkeys’ development process.
  • Shock where everything seemed to be really difficult. Kostas had to show the value of UX research, create a research space and creating research protocols to suit the games industry. Kostas’s plan was relying on the importance of dialogue: talking to people, understand what they do, and showing UX research helps them. This is where empathy is important but how do you do this? You empathise with the data and people and match it to research question.

  • Isolation or the fear you’re not going to make it. Having talked to as many people as possible, you need to accept the feedback and adjust your approach
  • Despair usually happens about mile 19 in a marathon. When you start to question if you really can do this, if you’re ready to do this and will it be ok?
  • The wall at mile 22 is when your brain doesn’t talk to your body anymore. You need to take one step at a time to keep going & identify mistakes and address them quickly. At EA, this meant all that earlier work to establish relationships with the team enabled collaboration. He had helped educate them & gave them ownership. The teams had begun the process of seeing the importance of data & value of user research.
  • Affirmation at mile 23 is feeling like you have a break thru. This is the stage Kostas is currently at work. He’s seeing people want to get involved in the UX research and wants to be able to sustain that team participation.
  • Elation at the finish line of mile 26 is when you’ve achieved the goal and need to shift your mindset towards the future. At work, this is what Kostas is working towards.

In summary, the DECEMA frame of reference that Kostas described – Dialogue, Empathy, Collaboration, Empowerment, Mutual respect and Advocacy – can take you a long way when introducing user research to your organization!

Thanks to both George & Kostas for a great evening and to Seek for hosting us!!!

seek

April wrap-up: The Making of Milanote

In April, one of the founders – Michael Trounce – of Melbourne startup Milanote, the notes app for creative work, let us in on a few secrets of their success.

Time

First of all, it’s been 3 years in the making. The 4 founders already have their own UX consulting business, Navy Design, and always had the ambition to start their own product business so back in 2014 they dedicated a week to working through potential product ideas. Ideas like a weather app and a hydration coaster were investigated then ditched (the coaster was referred to as a gimmicky Xmas present…).

They started working on a product which would solve a need their team had. Previously they had used post-its, a wiki, and other note keeping software but they all lacked a way to make connections and share.

During 2015, they began doing research with designers & other digital creatives and found there was a gap in the market for the product they had in mind. They build a (crappy) prototype & started using it in-house. They knew they were onto something when they found it worked better than any of their previous tools – whiteboards, Evernote, Trello, etc.

It later clicked that what they’d built wasn’t just a tool that could be applied to the UX design process, it was a tool that could be applied to any creative process. This insight broadened their market significantly and gave them the confidence to then break out the product from an internal project within the consultancy, to a product business in its own right.

It wasn’t until 2016 the focus changed to execution and as a result the hours of effort went up! They hired a small full-time team and ran a closed beta program for 6 months. Until then they were seeing where it would take them but those days were over.

They began granting early access when you referred friends and adding people to the waitlist by writing articles on Medium like ‘Why Using Evernote is Making You Less Creative‘ to get the word out (that article drove a lot of signups!)

When they did launch in Feb (2017), there was a flurry of press including reaching #1 on Product Hunt, the front page of Hacker News and #1 for the week on Designer News. It’s also been written up on Lifehacker and The Next Web covered it while it was in beta.

Challenges

Milanote can’t see your content due to privacy reasons. They have no idea what you are doing with their product or how you are using it which makes deciding on what features to build and understanding customers somewhat difficult.

To overcome this challenge, the Milanote team are using a mix of quantitative & qualitative methods to draw out data and feedback from their users along the different points in their product journey. The most obvious tactic is talking to its customers.

Michael from Milanote talking about the early days

A post shared by Product Anonymous (@product_anon) on

Pricing

They are continuing to evolve their thinking on pricing & looking at different models to help align the value of the product with the price.

Acquisition

The articles at launch including Product Hunt, #1 for the week on Designer News and word of mouth helped greatly with new customers. They need to experiment with other methods now to find scalable and repeatable ways of driving acquisition long-term.

Hiring

Milanote are currently looking for both developers & marketers. Check out their jobs.

AND the most shocking news of the evening!!! The Milanote team do NOT use post-its anymore! They have bare walls!

Thank you Michael for a great talk & elabor8 for hosting the evening!

March wrap-up: Learning from your customers via customer research

We had 2 great talks about customer research for our March session. Thank you Jo Squire & Katie Phillips, both User Experience Researchers from Australia Post, for an excellent evening!

FYI, we’ll be running another session on customer research in a couple months so hope to see you there!

Doing Research: Discovery & Validation – Jo Squire

thanks Jo for giving us an overview of the discovery and validation research #prodanon

A post shared by Product Anonymous (@product_anon) on

The research method you use will vary depending on several things including if you’re in a discovery or validation phase.

If you are in discovery, you might be looking for the problem or trying to get a better understanding of the problem. In this space, you’re looking for ‘why’ and it’s not at all the time to bring in prototypes! Observation, contextual inquiries and questionnaires are some of the methods to use here.

Once you move to validation, you’re looking to understand ‘how’ ie how is the product being used. Usability testing & co-design workshops are some of the methods you can use.

Jo reminded us that ‘research’ doesn’t have to cost a bomb or take a long time. No matter what your budget, everyone can incorporate research into their product. Low cost options include talking to your customers on the street, observing (potentially free!) & you can be creative about how you reward the participants.

Once you do the research, you need to communicate it within your organisation and the best way to do this is to include your stakeholders while you’re doing the research. If you can’t include them, try showing the video you captured during the research.

 

End-to-end validation & optimization via diary study – Katie Phillips

Katie talked us through a diary study she did for an Australia Post product. This was a product in the wild which was being constantly developed. Based on the research objective & other criteria, they decided to use a diary study & moderated user testing.

about to kick off katie’s talk about diary studies and how she used slack #prodanon

A post shared by Product Anonymous (@product_anon) on

Their research participants were not in the office so they choose remote user testing using live video/screen sharing for the user testing and Slack for the diary study. To select a research method there are several things to consider including the objective, how much time you have and your budget.

This is the 2nd time the AusPost team used Slack for research. Even though none of the participants had used Slack before, it was easy to onboard them and they understood how to communicate & share photos of their processes.

One of the things Katie talked about (which I think was amazingly fantastic!) is how involved the development team was during the research. They witnessed the screen sharing so knew right away about the problems users faced plus they scheduled time into their existing sprint so they could work on anything that came up during the research. Way to work together!

Katie shared a few resources:

Q&A time

Tips for the data

  • Always keep the raw data (ie video) so you can play it to the stakeholder
  • If a research company does the research for you, try and be with
    them for at least part of the sessions and ask them to send you the raw data
  • Tools for analysis – Depends on the research but they utalise Google sheets & post it notes a lot.
  • After you analyse the data, make sure it’s available to the project team & possibly other teams (to help with their problem solving).

Most challenging part of their job?
It depends on the project but often it’s recruiting of the research participants. Others include: having a prototype with the right tasks, getting clear objectives from stakeholders and deadlines that are very close to the product launch.

Are there tools for privacy/ethics/legal? Tips?
Make sure your participants know what is expected of them & that the product is being tested, not them. You should have them sign a non-disclosure agreement and your legal team (or participant recruitment company) will have other templates you can use.

Ethics-wise, you should ‘follow your moral compass’ but there’s lots of reading online to help

Thanks tons to Aconex for hosting!

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.