Invading the Product Landscape: Trade-offs and Being Lean

In Part 1, we introduced the Commando, Infantry, Police metaphor that we used to help TIM Group rethink how to transform ourselves into a new product company. The metaphor follows that we use commandos to discover how we invade our target market, infantry to storm across the market building market share, and police to keep our territory of the market peaceful. In this second part, we will discuss other ways that this metaphor and related concepts have caused us to rethink our product development.

The biggest shift was into a “commando” way of thinking. Given that it had been a long time since our current products were new, we needed to seek out more than a metaphor to find ways to improve ourselves. Another related space that we have taken ideas from is the Lean startup movement that was first proposed by Eric Reis and has since gone on to inspire others. A core tenant of Lean Startups is the focus on learning over revenue[1] (and learning over pretty much everything else). This focus on learning means that you want to minimize the time it takes from having a product idea or hypothesis to testing that idea in the market. This Lean Startup concept goes well with our Commando metaphor, as what the commandos want to do is try to figure out ways secure key areas of value (e.g. power stations, bridges, beachheads). Commandos don’t go in with huge forces, but with small numbers in a minimal way. Using a minimal force resonates back with the Lean Startup’s idea of a Minimal Viable Product, and the goal of the MVP as not to make some money or to build a cheap version of your product, but to prove that your product can solve the problem you think that you are solving. We need to create focused minimal forces to prove out our product hypotheses.

What this has also meant, has been a focus away from efficiency without sacrificing the effectiveness of getting an answer to our product hypothesis. As an example, let us assume that we have a new product idea involving a trading system that improves traders workflow so dramatically that we think that it can supplant existing trading systems. One feature that we may have to build to make it a viable product is trade pricing. Now the use case at its highest level might be simple: “price trades with the market rates”. There are many choices in implementing this feature: find a third-party provider of market data and integrate, create interactive admin screens for people to enter the prices, or price the data by hand (maybe even directly using SQL into the database). These solutions have trade-offs from the first (having large upfront development and investigation but requiring very little operational maintenance) to the last (having minimal upfront cost, but a large ongoing operational maintenance[2]). All of the solutions are probably equally effective, but we have a range of operational efficiencies. Which implementation should we choose? Taking on this “commando” way of thinking, we should focus on a the solution that gets us our answer sooner, even if that means losing out on efficiency in the short term. With a new product, we don’t even know if someone is going to use the product at all, let alone use it to the point that we have efficiency concerns. We have decided to build our experiments as cheaply as possible, so that we can learn as quickly as possible. Now, in time the product will no longer be “viable” (as in the “V” in Minimum Viable Product) with a heavily inefficient system, but by that point, you will have learned the lesson and the value of that product “territory”, so you should have the knowledge on how to make the product viable again.

Another efficiency/effectiveness trade-off that we have recently experienced was a resourcing one. We currently have around 25 developers with 20 of them focused on the new products. During the most recent round of resource allocation, we gave the developers a prioritized list of new product projects that we needed solving. The developers chose to allocate themselves to the two highest priority projects, even though their gut instinct was that they would be “inefficient” since there would be “too many” devs on the project team to keep busy the whole time[3]. They thought that they may learn a way to utilize all of them (or even more) to get the project completed earlier, and they should wait and see after some time working on the project before deciding that they truly were over-staffed. Getting the project completed earlier (and therefore sooner to answering the product hypothesis) at the cost of efficiency, helps us get us quicker to an answer of whether we can sell our product.

Another interesting point that caused us a bit of confusion early on was how quality fit into the picture. When people hear the phrase “build experiments to test your hypothesis as quickly as possible”, they might think, “Oh, I will just hack out some code then. No tests. Ugly screens. That’s quick.” That is *not* at all what we should do. When these trade-offs were suggested to the greater team (code quality for potential time-to-market[4] advantage), we confirmed with our teams that these products had to be as high as (or even higher!) quality than our past products. If we only have one chance for a client to use the system and it is buggy or looks awful, they likely aren’t going to look at it again. We should be focusing on simplicity, few features, and precise strikes on the high value questions that we need answered.

In Part 3 (to be completed), I discuss how we have gone one step further and played with the metaphor, enhancing it to better align to our new (and “old”) product needs.

[1] Geoffrey Moore said in a video interview at SAP (around the 21 minute mark): “The way you kill [new fledgling initiatives within a company] is to hold them to metrics that don’t make sense…”

[2] A new definition of YAGNI? “You Are Gonna Need an Intern”?

[3] Actually, another answer to this one comes from the original Lean/TPS doctrine: eliminating Muri, the overburdening of people and equipment.

[4] There is a strong argument to be made that low code quality or bad development practices will actually slow you down very quickly. Just maybe, that one feature will get done a little bit earlier, but you will pay that back many times over when you review/enhance/modify that code later on and the bad code gets in your way.