Hacking the product: Opus 1

Disclaimer: All the ideas expressed in this post are my own and don’t reflect the opinions of Lion.

I will tell you a quick story about myself: I usually said that I had 3 lives, one in each country where I lived. I would add that I had 3 professional lives: the first as a researcher in innovation management (my DNA), the second as a bartender/waiter and manager of trendy restaurants/clubs and the third is related to my life as a consultant in the heavy industry & digital strategy analyst in the banking world with a focus on Fintech and Cybersecurity verticals. It is time to me to open a new chapter, a «fourth life» through a deep dive into the product. I am trying now to understand “the nuts and bolts” of the product, think and act with a product-driven mindset to become a maker. My first step has been to be part of a programme powered by Lion called “Product Track” launched and managed by Barbara Vogel, formerly Product Manager at Voyages-sncf.com, RogerVoice and Shopify. She is now the CEO of Meraki aiming at «shaping» the next generation of product managers in France.

Here we go! Further to this program, I would like to share with you my 5 takeaways.

Identify the problem first, not the solution

During the first night, the idea was to figure out the role of product owner and to think about a problem for which we will design a digital solution at the end of the day.

The product owner (PO) is the guy who acts as an interface between the UX, the tech and the business. He is the boundary spanner or the translator between the different languages spoken by the designers, the developers, the business guys and the other stakeholders. During the session, we learnt how difficult it is to communicate its ideas to each other. One could imagine this challenge when it comes to design and develop the product between PO, designers, developers and scrum masters around the table.

The first challenge for us was to identify a problem in a specific industry (a real painpoint). Then, the group of participants was split into teams of 3 people. Each group pitched its own challenge and we finally selected the challenge to be hacked. The common denominator of the different problems pitched: they all affect more or less our lives and we all experienced these problems in our daily or professional life. Now, we have the problem, each team has to polish it.

It could be trivial what I will say but it isn’t: think about the problem, the challenge to take up, the painpoints and not the solution. During my previous experiences, I had the opportunity to discuss with people who were more interested by the solutions than the problems they face. They even did not know their critical problem. In the jungle of the business world, time is money. So people are obsessed by the solution without taking time to identify their real painpoints. Believe me, it is really tough to extract the challenge(s) in an existing business or when you want to launch a venture.

Framing the right user stories

After identifying the problem, the time has come to constitute the product backlog which is composed by different user stories that are prioritized. During this second night, we learned the modalities of the “agile manifesto” and the different scrum rituals and agile ceremonies. The agile manifesto is focused on the client satisfaction, a proactive attitude towards the potential changes in users needs which could occur during the project and the incremental, iterative and empirical approach to design and deliver the product.

I will point out for the readers the three things I really appreciate this night:

• Working on the elevator pitch which formalizes the problem and our value proposition to tackle the problem
• Building the Impact Map which is a visualisation tool which reconciles the global vision focused on the objectives and the micro vision oriented towards the technical features: from the “why” (the objective) to the “What” (the feature which will be discussed with the developers)
• Writing the first user stories to feed the Product Backlog: it is not an easy exercise but it enables to formalize each feature, specify the profile of the users/personas and describe the value provided.

Be user-centric, ask the users what are their expectations

During this third night, we had the chance to begin a real user research in the street in order to gather some insightful feedbacks. The aim of the exercise was to challenge our initial intuitions about the problem by asking people about their needs, painpoints and the alternative solutions they are using to take up this challenge.

• It is not easy to “hook” people in the middle of the street and create a trustful relationship during the interview which last around 10 to 15 minutes. The challenge is really to ask an open question at the beginning and let the users express themselves, then deepen the answers and ask why do you think this ?, why do you think that ?
• This exercise reminds my PhD thesis when I asked more than 100 managers, entrepreneurs and researchers. The idea during these interviews was to discover new things, gather qualitative insights and avoid different biases.
• In this session, I really appreciate the insights from the users and their expectations. The challenge in this type of exercice is to interview the personas that we previously selected and avoid as much as we can to introduce biases.

Finally, the user research enables us to confirm our intuitions or invalidate them. Then, the idea is to find a pivot of the problem we initially want to address.

Let’s now design the solution

The fourth night was dedicated to interactions with a designer. The goal of this session was to sketch a draft of the solution with paper and pencil and produce some wireframes. It was for each of us a first sign of satisfaction since we succeeded to illustrate the solution.

In the design process, it is the phase where we unleashed our creativity to make the solution real.

As you know, the design is an important part of the solution. A good design should be ubiquitous in the user experience and completely transparent for the users.

Some key takeaways the Product Owner should take into account in its relationship with the designers:

• sharing the information with the design about the context of the project and the business goals.
• leaving one step ahead to the designers for the conception before involving the development team
• contributing actively during the sketching sessions with the designers
• reporting to the designers the feedbacks stemming from the stakeholders and users
• defining KPIs to assess the user experience

It is time to interact with the developers

The interaction with the developers and understanding their language is also part of the job of the Product Owner.

After the conception phase, the development team should now develop and code the solution.

During this night session, we interact with a team of developers who challenge our user stories during the exercise of backlog refinement. The aim of this meeting was to present and explain our product backlog to the developers. Then, the developers assess each user story (through a “Planning Poker”) presented in terms of complexity and estimate the necessary effort to perform it.

I could stress for the readers 3 things which I discover. User stories should be:

• Accurate, valuable and dedicated to specific users
• Understandable by the developers
• Small enough to be developed
• Testable

Hallelujah, hack the challenge and pitch the product

This is the last day. The objective was twofold: an interaction with an expert regarding the “data mindset” to adopt + a pitch session to present the problem and the value proposition.

I will share with the readers some insights regarding the “data-driven approach” to adopt in a startup environment:

• There are 4 preliminary steps of data analysis:

1. Inspection : this step is equivalent to the definition of the need for the PO : the idea is to define the objective served by data and identify where we could retrieve the data needed
2. Data mining: website scrapping, retrieving data from different databases
3. Data cleaning: make data more digestible
4. Data transformation: convert data from a specific format/structure to another
5. Data visualisation: make data more impactful

I enjoyed also the different notions exposed regarding the analysis and the monitoring one could take into account

• Funnel: different steps through which a potential user will carry out to become a customer
• Cohort: bunch of users sharing a common denominator: age, gender or behavior. Cohorts enable PO to make some analysis such as the retention rate.
• KPIs: Retention Rate, Acquisition Cost, Lifetime Value (LTV), Churn Rate, NPS are some of them

We then got some tips brought by an expert in public speaking who emphasizes that 90% is related to body langage and the voice, 10% is related to words

We finalize this outstanding journey with a final pitch in front of top-rated Heads of Product and Product Managers.

Finally, I appreciated:

• the concrete way to address the challenges related to tech products: theory mixed with practice in each session in order to grasp all the pillars of a tech product
• the talented speakers of the programme
• the variety of the participants: smart, cool and professional guys!

I definitely recommend this programme