Rakuten: Product Development Lifecycle

A Rakuten achievement I’m most proud of has been creating and implementing the organizations PDLC (Product Development Lifecycle). Over time, I’ll add and update this post. I have a books worth of knowledge to share, so to keep it somewhat readable, I’ll just touch on some highlights.

When I joined Rakuten, the company was going through a transition from a service model to a Tribes & Squads model. With a new organizational structure, the team was faced with a lot of challenges. The first opportunity for leadership was finding ways to get individuals comfortable and productive in an environment that they may not have worked in before. Unfortunately, we didn’t nail this one. Inadvertently, the change created a sink or swim situation for the product squads. They were void of frameworks and coaches to support the transition, creating a “just figure it out” scenario. This had damaging effects on how we were determining what to build and how to deliver it. Having come from companies that successfully worked in a Tribe & Squad model, I saw an opportunity to help.

The first thing I did was to embed myself in squads ceremonies so I could understand how they were currently working, both in how they determined what it is they were going to build and how they were building it.

Some observations that I made:

Top down, “do this” approach directing the vast majority of the work (Legacy of a service model).
No predictability in how opportunities were discovered, planned, or executed.
Most projects started out too big and then scope would continue to balloon.
Lack of experience with true Discovery or Continuous Discovery.
No documentation or templates to guide teams through frameworks.
Slow cycles and it wasn’t clear who was doing what, when.

These problems are systemic, so I knew it wouldn’t be an easy shift.

A Triple Diamond?!

I began where I start most of my work, extensive research on what other experts in the industry are thinking and doing (competitor analysis, if you will). While combing through books and articles, I came across a Medium post that hit home, “The Zendesk Triple Diamond”. Reading this was an “ah-ha”! moment for me. For years I had struggled with implementing a strict Double Diamond into medium sized orgs. The reason is that the Double Diamond never really solved for validating product solutions and prioritizing prior to spending development time on them. In medium sized orgs, development costs of a solution that isn’t successful can be incredibly damaging to the businesses revenue goals. For me, the question has been, “what is the best way to validate, then prioritize, then build?”

The Double Diamond framework has always been a “fail fast and break things” approach. In in start-ups, I find that to be very valuable. But that said, I’ve always been interested in succeeding fast. Zendesk’s inclusion of a third “Delivery” diamond was what I had been looking for. It gives squads permission to not to build things that haven’t been validated.

In parallel, I started meeting regularly with some of my squads. “Trio” (Product Driver, Product Designer, and Eng Lead). The intent was to understand better how they were doing their work and where I could help. Here I introduced documentation, templates, articles, and opportunistic training (hopping in when the opportunity presents itself to be hands-on).

Next, I assessed where my Product Design team was in terms of understanding of Discovery, Agile implementation, and how we determine outcomes, measure, and then respond. There was a lot of work to do, but I knew if I trained my team they would evangelize the frameworks and coach others that needed some help.

Click here for some simple and free templates.

So What Next?

After an affinity mapping session I had a pretty good grasp at the top level opportunities to address and I took to the whiteboard. As I sketched through solutions, I met regularly with our Exec and Leadership team to push the concepts. I also had drop-ins with PMs, PDs, and Eng to get feedback.

I started with the tried and true Double Diamond, where we spend the first diverge/converge phase understanding what the problems/opportunities truly are, the second phase where we collectively align and work to solve. Next, I added in the Rakuten version of the Delivery Diamond.

Although I had fully embraced the Triple Diamond model that Zendesk created, something was missing - what you do after you deliver the product? We all know that you have to measure it and then decide whether to iterate, maintain, or sunset the product or feature. This resulted in a fourth diamond for us. The SVP of Eng was a big driver for the forth “Measure and Decide” diamond as he felt that orgs rarely put any emphasis on sunsetting, anything. Music to my ears.

The result:

Implementation

Now that we had a framework, the hard work starts… the mindset shift (Teresa Torres has a chapter on this in Continuous Discovery Habits). Probably one of the hardest habits to break is shifting from output to outcome as the inspiration for Product work. It so natural to make a big list of things one thinks will fix problems and plop them neatly on a roadmap. Anyone can look at it and say, “yeah, seems right”. But, it never works and everyone knows it. Too many times I’ve heard product leaders say, “I know, we’re only going to deliver half of less of this list.” Why make the list so big then? It’s not motivating to deliver half or a quarter of your teams list. Focusing on quantity over quality is head scratcher. 100 pennies is a lot of quantity, but I’d rather have a $100 bill.

So what do we do? First, we get the product squad leads (the Trio, not just the PM) determining their objectives (aligned to the company objectives). Once they’ve set their focus areas, they determine key results, eg; the metrics that govern success. Those metrics need to be actionable, auditable, and accessible.

TL;DR, get teams to stop falling in love with their solutions and getting them to fall in love with their problems. An ongoing exercise.

Where Are We Now?

We’ve sent 7 Influencers from the org to the Silicon Valley Product Group’s training seminar in hopes to not only teach and understand roles and how to best do Discovery, but to also start opportunistic training with squads.

Next we’ll be embedding a Discovery coach in a squad to validate that proper Discovery leads to better results. As we continue to test and implement this model, we’ll inevitably adjust it. But so far the org, from our CEO to our IC’s are excited for the framework and have been making excellent progress on the areas where we needed the most help.