Building internal product, a build trap’s rabbit hole

I’m an engineer which mostly worked on internal product. In my previous job I built internal observability systems for thousands of LINE’s engineers. In my current job I’m building internal platform for thousands of ops member, risk supports.

The hard thing of building internal product is, most people don’t see internal product as a “product”. Many people think internal product as a “simple tool” which do not need roadmap or proper management, which is just simply wrong. Even many senior managers think internal product as “cost center” (which mostly “spend money” instead of generating revenue), which make the situation even worse.

At the time, lacking of product management knowledge is our team most painful point (failed find ‘true’ Product Manager role is one of the cause, but finding Product Manager for internal product is mostly impossible in Japan market).

Recently I read a book called Escaping the Build Trap from Mellissa Perri. Reading the book made me feel that I should have read it sooner. The book had some very intuitive and simple guide for people that don’t have much experience in Product Management field, to escape from what she called 'build trap’, which is a rabbit hole of shipping feature that nobody use, while can’t get enough sponsorship from upper manager.

There were many things that I learnt from the book, to name the few:

• Product Manager role is to explore the 'what’ and the 'why’, while the Engineering team (Engineer Manager, Engineer, Project Manager) focus on the 'how’ and the 'when’

• Any company should know about strategic thinking, how to define vision, goal, and communicate those visions across the company

• Any product company should be outcome centric instead of output centric, and know how to measure those outcomes (metrics) is also very important

Book detail

Output centric confusion

Many companies focused on 'output’ culture, not 'outcome’. Our previous team did the same.

But the culture came with trade off, we so focused on shipping features, we celebrated big releases, but we mostly forgot to follow up the question Are those features being used??

It’s about confusing output-centric measures of progress with real measures of value.

Product vs Project

The book has a very concise definition of 'product’ and 'project’. Confusing between those 2 concepts may easily lead to an organization which just keep creating new project which deliver nothing to users.

A Product is something needed to be nurtured and grown to maturity, this takes a long time. Product are vehicles of value, which deliver value repeatedly to customers and users, without requiring the company to build something new every time

A project is a discrete scope of work that has a particular aim

What product manager do?

In the book Mellissa wrote few things about 'Product Manager’ role that I feel very important

One of the biggest misconceptions about the role of a product manager is that they own the entire product and therefore can tell everyone what to build.

Product managers really own the 'why’ of what they’re building

The title 'Product Manager’ is misleading in itself. An effective product manager is not a manager

Those facts are indeed very reasonable. For small team like my previous team, we didn’t have a luxury of a dedicated 'Product Manager’. We had only one role 'Engineering Manager’ that did almost everything, from Product Roadmap, User Investigation, Mentoring to Technical Architecture.. Wearing many hat is obviously bad so I don’t have to explain why it’s bad here.

But we have to admit that, NOT many team has resource for a dedicate Product Manager. But even you have to wear many hats with limit team resource, know the boundary of the role is very important to guide you to do correct practice.

Strategy is NOT a plan

When the company pay hundreds of thousands of Dollars for their employees, the biggest expectation from the company is 'Autonomousity’. Autonomy is what allows organizations to scale (which limit to company that build their own product, not outsource company).

But even with high autonomous employees, they can’t just sit there and doing things on their own, without any direction. They need framework and vision, which could be translated into 'strategy’

A good product needs a good strategy, not one-time plan.

Good strategy isn’t a detailed plan. It’s a framework that helps you make decisions. Thinking of strategy as a plan is what gets us into the build trap.

So what is strategy, and how to create strategic framework?

A good company strategy should be made up of two parts: the operational framework, or how to keep the day-to-day activities of a company moving; and the strategic framework, or how the company realizes the vision through product and service development in the market

To make up detail strategies, we need something call 'Strategy deployment’

Strategy deployment

Strategies are interconnecting stories told throughout the organization that explain the objective and outcomes, tailored to a specific time frame. We call this act of communicating and aligning those narratives strategy deployment.

Strategy deployment has different appearance across company layers:

The first two are at the company level, whereas the last two are specific to the products or services of the company. Strategy deployment and strategy creation, though, are two different things

Strategy creation

Strategy creation is the process of figuring out which direction the company should act upon and of developing the framework in which people make decisions. Strategies are created at each level and then deployed across the organization.

It’s pretty cryptic definition, so I think we could understand strategy creation is

• (1) Process of figure out 'what to do’ to full fill visions / and resolve intent

• (2) A framework of 'how’ people iterate their product, make it better

There is well known improvement framework (2) practiced at Toyota called Product Kata

Build and optimize your product

There are multiple steps to optimize your product, starting with Problem

Problem Exploration → Solution Exploration → Building and Optimizing Solution

It’s easy to fall into the trap of solving problems before you find their root causes. We’re all prone to problem solve, even if we don’t know what the problem is

Engineers, since their nature is curiosity, easily fall into building things which solve nothing, just to satisfy their curiosity. So explore the 'why’ carefully is one important job of product manager to escape from building trap.

When you know possible 'why’, the next important things is explore solution. The word explore has uncertainty inside it, the book suggest few methods:

• Concierge: could be understood as a 'manual’ solution. Especially useful for B2B product since you don’t have to do many things at scale.

• Wizard of Oz: could be understood as a 'mock’ solution, which 'looks and feels’ like real product but behind the scene is all manual. This method is famously employed by Zappos, to build their only shop entirely on WordPress.

• Concept Testing: just straight forward as its name, you demonstrate the concepts to the user to gauge their feedback

Despite any method you choose, the most important concept behind the 'Solution Exploration’ is its uncertainty, which means that you need to persuade the upper manager to give you enough space to 'explore’, to learn and fail.

Product managers need a certain amount of trust from the organization to have room to explore different options.Learning should be at the core of every product-led organization. It should be what drives us as an organization. It’s far wiser to look at funding product development like a venture capitalist (VC). Startups must pitch investors on their vision and on the data they collect to prove that the vision will be viable and profitable in the market