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.
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.
📌 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 !
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.
📌 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:
Then, we went througf the ideation phase t :
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.
📌 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 :
👉 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).
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 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.
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:
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:
Roles were set, now we had to make sure we had a decision-making machine, to fail fast and succeed sooner !
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.
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
January 15, 2019