Product idea inception – discovery exercise

I became much lazier during the last couple of years – I need to hear a good reason to start doing something. The same when it comes to work – “why?” became one of my favourite questions. I discovered how many things are done without the reason. Ask “Why do we need this new type of report?”  and then repeat the question unless you get deep to the real reason. When you finally get to smth the like “Because everyone does it!” – you can show the maximum understanding of the problem on your face while leaving the room and going to the kitchen to prepare a cup of coffee and get back to reading Reddit. Try and you’ll be surprised too.

So, when I faced the new type of tasks in our company I tried to implement the same procedure. The case is that we had a significant amount of incoming requests from the potential clients who  are on the initial stage of their product development – “I have a great idea”. No great details, no understanding if it may work out or not, no feature lists, prototypes or smth similar. But we wanted to work with them! Because their ideas are great, because they are great people, because it is more interesting to have crazy workouts with them than speaking to the wet blanket corporate clients. So, we gathered around the problem how to kick-off such projects. Using the knowledge and experience of very smart people (luckily IT is full of such guys!) we started performing “product inception sessions”, not 100% the same for all projects, as they are very different – some have just and idea, other;s come with the real strategy, but know nothing about mobile development. I’ll try to describe different approaches we use. Let’s start with the “worst scenario” – “help we understand my idea”. We can’t just start development, as we have no idea what to develop) Starting development on this point will mean just throwing money out of the window.

This thing is much inspired by the Luxr workshop. Thanks for them for gathering all the information and presenting the well-known approaches in the new shiny package. Also thanks to all my colleagues who participated.

User-centred design

As we are going to use user-centred design, the first thing we should do is to understand our users. Of course, you feel as if you are the same person as your users and you know what they need and how they’ll behave. Be prepared that it is not true. You are going to work in the conditions of the full uncertainty, predictions, fails.

We’ll go through:

Session schedule:

1. Introduction – 15 min
2. Discussing the product idea – 15 min (Try to moderate this stage properly – the idea owner should be prepared to describe the idea shortly, so anyone get’s the main point. No discussions at this point).
3. Hypothesis – 15-20 min
4. Personas – 30 min
5. Personas verification – fieldwork
6. Customer needs – 30 min
7. Metrics discussion – how to prove the hypothesis.
8. Hypothesis prove/fail – fieldwork
9. Retrospective

Partisipants:

• product managers/owners/etc from the client side
• designers/developers/managers from our side (anyone you can catch in the corridor and pull to the meeting room)
• facilitator (checks everyone is awake)

So, let’s start: we are going to discover our main hypothesis and find out how to validate them.

Hypothesis

The form you can write it in is: “We believe that people like _______(customer type) have a need for (or problems doing) _____(need/action).”

Cooperate with customer to find out what is the core hypothesis you want to check first. It should be the reflection of the basic need you are going to satisfy with your product. Do not forget adding “We believe”, as if you don’t believe, what you are doing here?

Personas

Personas are our users) It is a fictional character to represent certain user types of your target group. It is great if you can create 3 to 5 personas for your product. We want to know who the person is, what they value, and how best to speak to them.

Ask all of the participants to take paper sheets and be prepared to describe the persona they have chosen:

• Start with naming you persona and draw his picture. Don’t worry if you can’t draw – just use the basic circles, rectangles and lines. Use different colors – make you person be alive) Sometimes we use the photos of the people, but it is better to start with drawing, as you can imagine this person better. (It should take no more than 7 min. Everyone draws by himself in silence. Spent 5 min presenting the pictures).

Using photo to present persona

• Ok, we are done with the portraits. Let’s now describe the “Demographics” of the person: age,  profession, family life, etc. (5 min for everyone to get done with their person, short presentation afterwards).
• The next part is “Behaviour” – What the person does everyday? How he/she feels? How often he/she performs these actions? (Give everyone 7 min to brainstorm and then discuss together).
• The last is “Needs/Goals” – describe person’s goals, his problems, intentions, needs. The same as for the previous steps – spent about 7 min on writing down needs and goals and then everyone should present the ready person to the group.

As the result you should have smth like this:

Now it is a perfect place to ask the questions: Are our personas accurate enough? Are they real? Are they our real users? The next step would be verifying our personas, but we need to go outside for that and meet the real people.
I think, the best way of finding out more about your users (and many authors agree with me) are interviews. You should prepare the user interviews sessions and process the results, so you can modify your personas to represent the real users. I will describe the user interviewing in a separate article. After that you definitely need to revise your personas.

User’s needs : What users can do with your product?

Ok, we have idea about our users, we have our product idea. But how they intersect? How users would use our product? Does it fit in their real life?

Sometimes you can come across the situation when you create a lot of wonderful features, but people are not using them – there is no place for them in their activities. For example, you are creating the application for snowboarders. You add the feature to notify them that their friend is nearby, or messaging function. How do you suppose snowboarder will use it while boarding? He has no time to look at the screen. He can’t take of his handcuffs to write a message while he is driving down the mountain)Sad to find out that when you finish working prototype and perform real user testing with snowboard fans.

So, let’s imagine the situations when our users interact with our product and visualize them.

Everyone should be prepared to draw small sketches about the real life situations. Give participants up to 10-15 min to fill their paper sheets with 4-6 sketches:

After that each should present their storyboards. Discuss the situations, try to locate the common patterns. The purpose of this exercise is to intersect user needs and our product vision to show the value we are going to bring to the user. Also it informs which features are the most important.

Proving hypothesis

You can’t prove or disapprove anything while you have something to measure. So the next important step is to find out which metrics we’ll use.

The most important questions, which we are all thinking about is “Will people use? Why yes/no?”

Here we come to interviews, user testing, a/b testing, etc. We are not visionaries no be able to say what will happen. So the only way to find out is to perform experiments. It is much cheaper than building the product and than throwing it away.

So, we choose some metrics, like “number of people who subscribe for the future service” and perform experiments. It can be, for example, the “fake” landing page for the future service which describes the main idea and has a “Leave your email and we’ll notify you” button to check if people are interested in the idea of the service or small working prototype. As it is a kind of “test” you should describe it the same as you do with you test cases for software: write the “happy path” and it’s conditions.

What if the hypothesis is wrong?

You performed several experiments and results are negative. That is great! You saved a lot of money and rain forests on Amazon river! You need to modify your hypothesis or create a new one and go over the process once more, more and more, while the results are positive.

Retrospective

As I am crazy about improving everything – any of my meetings can end without retrospective. I believe that this is one the most important parts, as it is helpful to continually improve the process. Participants should give some constructive feedback to the facilitators so they can sharpen their skills.