From Zero To Product Owner: Setting the conditions to succeed with Agility

Launching an insurance e-commerce product in less than 6 months with no budget for marketing research, surveys, UX design, and a newly assembled team.

Mexico City, 2015. I was taking over my second job in an insurance company, after a year as consultant in a strategic design consulting firm. On my first day, my boss told me my mission was to build and launch an insurance e-commerce product in less than 6 months.

I had no budget for marketing research, surveys or UX design. I had no team either, nor a clue about what an insurance product or coverage was, how it was priced, who operated it. I didn’t know the Mexican market so well… and even less the insurance sector.

But I was pretty excited to get it done.

In this article, I describe how I framed the problem through design of the Minimum Viable Product (MVP), and how I managed the transition from project leader to product owner.

(1) How I started: design thinking principles

Since I had some experience in strategic design, I decided to follow the first 9 steps of design thinking to frame the problem, come up with a solution, and define the MVP. I then switched to agile methdology for the developement.

1. Set the ambition with the right people 🚀

📌 a + b: Observe & Understand

I started meeting many people who would be involved in the project: managers, staff, experts, marketing guys, etc… I wanted to catch the context, understand the governance, the political game and why we would collectively undertake such an initiative.

📌 g: Storytell

I then gathered the two sponsors of the project, the head of business line and the head of innovation, to set the vision: the story to be told to anyone we wanted to onboard, the purpose we would give to the one about to work on the project. “In 2 years, we aim to … that is why today, we will …”

I then managed to have an actuary who would help me at 50% on the topic: he was my first team member !

2. Secure sponsors who have real influence 👌

As having no team, and no resources, I understood I would have to count on managers donating their teams’ time. A little lobbying was necessary.

After having understood the landscape, I could start identifying who would become instrumental for the good delivery of the project. There were three kinds of people: sponsors, neutrals, and stoppers.

It was absolutely necessary to onboard them since the beginning and ensure they were part of the story being created. Sponsors were incredibly helpful when we needed to unlock a situation or to push for a decision to be made.

👉 Engage potential stoppers seemed to be a good strategy, as being part of the story since the beginning, they couldn’t blame us for moving forward, as they were part of the decision-making process.

3. Engage since ideation all stakeholders 🏬

📌 c + d: Point of view + Ideate

It is important for two reasons: (i) because we knew we would need the help of these stakeholders afterwards, so better let them be contributors, and (ii) because it was key to identify what had been done in the past and detect underlying risks.

We led the two workshops with finance, legal, pricing, marketing, operations, distribution and IT.

First, we defined the problem and key success factors by gathering the following information:

• Similar projects and their outcomes
• Learnings from failures in the past
• Potential risks and preocupations
• State of the market and competition

Then, we went througf the ideation phase t :

• Identify our targets and their purchase behaviours (for instance, we identified that women were decision-makers but men were the shoppers, and that online users were not only price sensitive but smart shoppers : they needed available information to compare offers quickly)
• Generate a maximum of ideas to solve the problem stated
• Select the best concepts (we came up with ‘transparency’, ‘saving’, ‘family protection’)
• Create the target value proposition
• Determine the first MVP

That part was tricky, as it started to involve IT specificities. We had included an IT representative who would often bring us back to reality.

4. DIY ✂️

📌 e + f: prototype & test

Before jumping into developements, we tested the value proposition and the product: which coverage is more important than another? How does the wording and tone impacts the purchase? Do our target understand the product?

This is how we proceeded :

• We created surveys to test the appearance of the product, the name, and the workflow. We targeted friends and family who were in our targets: in less than a week, 101 people answered our 5 questions.
• We prototyped an app using POP to test the workflow Marvel
• We tested InVision prototypes in the street with 10 people to gather their first reactions InVision
• We also tested the IT solution: were the rules defined viable ? How would they impact other components of the system ?

👉 Do not make suppositions. Even with no budget, you can prototype and ask a bunch of people what they think. Just make sure to ask the right questions.

We had now our MVP mock-up tested and ready to be developed…but we needed a scrum team as well as a budget (we were one and a half at the time).

5. Negotiating a budget 💰

We knew what we wanted to test and how. Now we needed to ask for money to fund our scrum team. We did a 2 years business plan, as a symbolic move to initiate discussions with financial instances in place.

Our proposition was to get budget to pay for our team and adhoc experts during 6 months to launch the experiment and get enough insight through iterations to decide to continue or abort the project.

• The team we managed to get was made of two front end developers, one backend developer located in India, one scrum master and myself, two actuaries at 25% and 50%. A business analyst would then join us to assist me in user story definitions and impact analysis. We relied on an agile coach for free when needed 🙏, and on 3 experts (backends, architect) called Subject Matter Experts (SME) forecasted at 4 days a months
• The experiment was to test the market appetence and verify hypothesis: (i) the product enables 10% upselling to the upgraded product (ii) the product answers to a target we had not satisfied yet (iii) the product enables lead retention

(2) From project leader to product owner

The transition from project leader to product owner is tricky. Both roles are key but still very different. To manage smoothly the transition, I had my stakeholders agree on the rules of the game, clarified the roles, and set up a governance.

1. Set the rules of the game

What does it mean to be ‘agile’ in a waterfall-IT organization ?

For me, there are two components of agility: the methodology, and the mindset. My Scrum master and I started to set the rules and conditions of success, following the Agile Manifesto. If we were about to develop following the Agile methodology, internal financial, reporting and IT processes would have to be adapted. It means:

• Less documentation, more interactions: we managed to have our backends developers in India involved in all agile events (dailies, sprint planning and retrospective), by call conference, to avoid excessive documentation
• Flexibility over planning: we adapted the budget validation process not to wait the kick-off of the project and heavy business plan submissions. For instance, we agreed with our financial and reporting team to produce the sales reports ourselves: as we wanted to test the market first, we hadn’t included in the MVP the reporting feature. Our product wasn’t ‘visible’ in the data centers from which the monthly sales reports were made
• People over processes: we had required the ability to benefit from 50% of the time of a QA-person and an architect. It was helpful for us when, for instance, we ran a week of testing to make sure our first release would not affect the quarterly release updating all the quoting tables

2. Set the roles & accountabilities 👩

At this time, only one or two teams were Agile. The whole company ignored what the methodology, the mindset and the rules were about.

I evangelized simply the agile organizational model, explaining who is doing what and when. I had my stakeholders agree on the different roles:

• the product owner prioritizes the backlog, makes decisions and informs the governance
• the scrum master facilitates the teamwork, protects the team and make sure to find resources. Many times, our scrum master was helpful in fighting for our team’s right to adapt internal processes like security and overcome bureaucracy
• the team members were the developers and a business analyst who were modeling, developing and testing the product
• the stakeholders were direct or indirect users supporting, funding or having interdependencies with the product. We relied on the two actuaries who helped us design our product in a way we would appeal to our target without taking too higher risks in terms of claim frequency and severity (the product was displayed only for some states, a range of age and some models of cars)
• ad-hoc experts, like testing or architect experts, shall be available to be asked for help

Roles were set, now we had to make sure we had a decision-making machine, to fail fast and succeed sooner !

3. Enable decisions to be made on time 🔨

I set up a 3-week frequency meeting of 1 hour to mitigate risks and make key decisions.

Attendees were the head of motor business line, head of innovation, digital transformation officer (who I was reporting to), head of e-commerce, head of motor projects. The developers and the scrum master would not attend (only twice for a demo show). Sometimes we would have special guests to talk about a specific topic.

Typical agenda would cover main advances, solved bugs, and key decisions to make like internal or external communication, feature prioritization for the next sprint, etc… I remember a meeting were we had to choose between website performance optimization and code cleaning versus ux optimization.

👉 We would not spend more than 5 minutes on the advances, as demos were released at least weekly (if not bi-weekly) to get business feedbacks.

📌 g: pilot

The governance I set since the beginning improved meanwhile we started the development. It was key to have a human-sized structure around our product development to ensure right strategic and tactical directions and keep transparent communication.

To wrap it up…

Being agile in a company were most teams are not requires education (and self-upskilling), clear rules and accountability, adaptations of internal processes, and strong sponsorship from the top management.

As usual, mindset is at the core: I had the luck of being able to carry and onboard key players and help change their habits.

I had also the luck of having a wonderful team who were legitimate to ask for trust, and we got it!

At this moment we were facing the next challenge: deliver a working product and validate our hypothesis with success. I am talking about this topic in this article.

Credits to Yemsel Bougherara & @Elsabernard for the proofreading