Use of the guidelines

These guidelines are based on design thinking best practices. Whilst we encourage you to use these guidelines, it is not mandatory and you should approach your task in the way you believe is most likely to achieve your goal.

How closely you follow guidelines will be analysed in retrospectives. If you chose to deviate from the guidelines and the results are poor, it is likely you will be asked to give your reasons for not following the guidelines, and to follow the guidelines in the future.

If deviating from the guidelines consistently achieves better results, we will learn from this and use the deviations to iterate and improve the guidelines.

Whilst the exact methods used are up to you, you must document your product discovery thoroughly in Confluence. This is non-optional. The end-to-end process for documenting in Confluence is described here.

The guidelines use design thinking methodology

These guidelines are based on design thinking which has been popularised by companies such as IDEO, and used to great success to build successful products by Apple and others.

Design thinking isn’t a perfectly linear process, and each project is different. But no matter what kind of design challenge you’re working on, you’ll move through the following phases:

By doing deep research and gaining rapid feedback, you’ll build deep empathy with the customer you’re designing for. Following the design thinking methodology will allow you to:

• work out what is the most high-impact thing you can build at that moment in time

• figure out how to turn this into a new solution

• prototype and test solutions before Moniepoint spends the time, money and effort involved with building them and putting them out into the world.

Design thinking is a big shift from what we do today

Today, Moniepoint does little product discovery, and what does happen is really usability testing. In addition today the customer is a minor stakeholder, when they should be a major stakeholder.

Typically the approach we take today is to start with what’s feasible, then jump into building.

The new process will ensure we balance each of what is desirable, viable, and feasible. We will use product discovery to find what is desirable, then give proper attention to business viability and understand if it is feasible or not from a high level, before we start focus on the technical implementation.

We will build prototypes first and try to make them fail. We will find out from the customer- who is a major stakeholder- what could make our prototypes better, always aiming at the big innovations that can be a quantum leap forwards for Moniepoint.

We will test and iterate our prototypes a number of times, so that by the time we pass a product to our engineering team to build, we know it will be popular with customers.

Stage 1 - the problem to be solved

Building a roadmap

Product Managers will receive initiatives from a wide variety of sources:

• Growth (encompasses all that impact revenue)

• Compliance

• Customer feedback

• Engineering (technical debt)

• Finance

• Others

Product Managers should gather all initiatives. The list of all initiatives should then be prioritised. We have created prioritisation guidelines to help with this.

This will allow Product Managers to create a roadmap for their team with clear priorities. This roadmap will contribute to the roadmap for the business unit, which in turn will contribute to the company-wide roadmap.

Single team, multiple team, and multiple business line projects

If an initiative involves only a single team, it is managed by the Product Manager in that team. That Product Manager is solely responsible for product discovery.

If an initiative involves multiple teams within a single business line, it is managed by the Business Leader for that business line. The Business Leader co-ordinates product discovery across the teams under their control.

If an initiative involves multiple business lines, it is managed by the CPO. The CPO co-ordinates product discovery across all of the business lines involved.

New products

For completely new products, a Product Manager acts as the CEO of that product. This individual fulfils all roles in an acting capacity, and backfills roles in order of priority.

A Business Leader will be hired once the product is validated, and it is expected that the product will be a big / important area. If it is expected to remain a smaller product, the Product Manager can continue to run the product.

Stage 2 - KPIs and project foundations

Establish KPIs

The business KPI that the Product Manager or Business Leader wishes to affect with this initiative should be re-stated. This is to ensure the KPI and rationale for doing the project is crystal clear to all team members.

Create a project plan

Set the goal, key tasks, timelines, roles and responsibilities.

Stage 3 - research

Desktop research

Design thinking always starts with talking to people about their challenges, ambitions, and constraints.

To be able to do this effectively, you’ll need as much context, history, market knowledge, and data as you can, prior to commencing customer interviews.

We have created a template to help offer some inspiration on what research you can do, seen here.

Identifying customers for research

Identify who you will want to talk to for customer research. Who do you really need to hear from?

Aim to have a variety of interviewees:

• Moniepoint customers & non-customers (if customer-facing)

• Variety of internal stakeholders (if internal-facing)

• different ages

• different genders

• different ethnicities

• different professions

• different social position, etc.

The below section explains that each interview will need to be 45-60 minutes, and ideally face-to-face.

We have created a template table to help record interviewees details, seen here.

Interviews

Guidelines for interviews:

• Interviews should typically be 45 minutes long at least. The aim is to get deeper understanding to supplement that you gathered from quantitative data, surveys, and usability testing.

• Try to have two people of your team in each interview. One person can take on the role of the interviewer, leading the conversation and building trust with the interviewee, while the second person acts as an observer/note-taker, capturing key details, behaviours, and insights that might be missed by the interviewer. This allows for different interpretations of the responses and leads to richer insights as each person may pick up on different details or nuances in the conversation.

• Come prepared with a set of questions you’d like to ask. Start by asking broad questions about the person’s life, values, and habits, before asking more specific questions that relate directly to your challenge. A pro-forma template you can use to help formulate the right questions to ask is here.

Keep questions at a high level at early stages- do not dive into specifics on a product, or specifics such as asking ‘do you like this feature?'.

We are trying to understand core user needs, desires, hopes and fears. This will allow us to create a far more comprehensive and high-potential product, than simply doing usability testing.

Synthesise your findings from the interviews (research download)

• Take key extracts from the notes you took, and put them into post-it notes (use a virtual tool such as FigJam or Lucidspark).

• Do this the day of an interview, or maximum the day after, as the insights and quotes should be fresh in your mind.

Identify themes

As you gather your learnings, patterns and themes are likely to emerge. Here’s a guideline for how to spot and identify themes, and make sense of them:

• Gather around your post-its from previous ideation sessions (as a team if possible). Move the most compelling, common, and inspiring quotes, stories, or ideas to a new board and sort them into categories.

• Look for patterns and relationships between your categories and move the post-its around as you continue grouping. The goal is to identify key themes and then to translate them into opportunities for design.

• Take the themes that you identified and rephrase them as a short statements. You’re not looking for a solution here, just transforming a theme into what feels like a core insight of your research.

• Aim for the three to five most impactful insights.

A template to help identify themes is here.

Stage 4 - ideation

Create How Might We questions (HMW)

Now turn your themes into ‘How Might We’ questions. The aim of these questions is to inspire creative thinking when ideating prototypes.

A template to help you do that is here.

Brainstorm ideas

Brainstorm ideas for solutions to each 'How Might We' question. Do this with all your team present.

• Focus on quantity, not quality here. Generate as many ideas as possible. In a good
  session, up to 100 ideas are generated in 60 minutes.

• Prioritise creativity over immediate feasibility.

Bundle brainstormed ideas

Now that you’ve got lots of ideas, it’s time to combine them into robust solutions.

Bundling ideas takes you from strong individual concepts to solutions of substance. Think of it as a game of mix and match, with the end goal of putting the best parts of several ideas together to create more complex concepts. You’ve probably noticed that many ideas start to resemble each other—which is a good thing. Try different combinations; keep the best parts of some, get rid of the ones that aren’t working, and consolidate your thinking into a few concepts you can start to share.

• Start by clustering similar ideas into groups. Talk about the best elements of those clusters and combine them with other clusters.

• Once you’ve got a few idea groupings, ask yourself how the best elements of your thinking might live in a system. Now you’re moving from individual ideas to full-on solutions.

Now you’re moving to the first solution for testing, which contains a number of new and creative ideas.

Create a prototype

The goal is to get a robust, flexible concept that addresses the problem you’re trying to solve.

• Keep referring back to the KPI you need to improve. Is this directed towards it? Are there elements missing in your solution? What else can you incorporate to come up with a great solution?

• There’s a bit of trial and error here. And creating a concept means you’ll probably create a couple that don’t work out. This process is about learning, not getting it right the first time. Better to test a miserable failure and learn from it, rather than take ages making a beautiful, highly refined prototype.

Get real feedback

• Now that you’ve got a prototype to share, get it in front of the people you’re designing for.

• Capturing honest feedback is crucial. People may praise your prototype to be nice, so assure them that this is only a tool by which to learn and that you welcome honest, even negative feedback.

• Share with lots of people so that you get a variety of reactions.

• Write down the feedback you hear and use this opportunity with the people you’re designing for to ask more questions and iterate your ideas further.

Integrate feedback into your prototype, and iterate

• Note down and gather all the feedback you gathered in the previous step. Note- wait until a batch of interviews are done and iterate your design based on aggregated comments that you’re hearing over and over again- don’t get sucked into iterating the product based on a single piece of feedback.

• Build the next iteration of your prototype, based on this feedback.

• Remember that this is a method for refining your idea, not for getting to the ultimate solution the first time. You’ll probably do it a few times to work out the kinks and get to the right answer.

Stage 5 - design & handoff

Following the completion of the above steps a clear value proposition should be formed, with a prototype that is validated with customers.

At this point, you will progress to the design & handoff stage.