The Summit is Just a Halfway Point

(Title is originally a quote from Ed Viesturs.)

This past week, TIM Group held its Global Summit, where we had nearly all of our Technology, Product, and Sales folks under the same roof in London. For those who aren’t aware, we are quite globally spread. We have technologists in both London and Boston offices (as well as remote from elsewhere in the UK and France), product managers in our NYC/London/Boston offices, and sales/client services folks across those offices as well as Hong Kong and Toronto. This summit brings together teams and departments that haven’t been face-to-face in many months — some teams haven’t been in the same place since the previous summit.

On the Monday, we got together for an unconference (in the Open Spaces format.) This was a great way to kick off the week. We were able to quickly organize ourselves, setup an itinerary for the day, and get to it. We discussed what people truly thought were the most important topics. We had sessions on everything from “Where does our (product) learning go?” (about cataloging the knowledge we gain about our new products), “Deployment next” (about where we take our current infrastructure next), and many other topics across development, product management, DevOps, QA, and beyond.

For the more technically-focused of the group, the rest of the week was filled with self-organized projects. Some of these were devised in the weeks leading to the Summit — some were proposed on the day by attendees. There were so many awesome projects to be worked on last week. We had ones that ranged from investigating our company’s current technical problems (like HA task scheduling), creating tools to solve some of our simple problems (like an online Niko-niko tracker), or solve some bigger-than-just-us problems (like Intellij remote collaboration.) You should expect to see us share more about these projects on this blog. Stay tuned!

To be clear, it wasn’t all fun. We also had a football game, beer tasting, and Brick Lane dinners. Altogether, this was a great opportunity to re-establish the bonds between our teams. While there are many benefits to having distributed teams as we do, there are many challenges as well. We do many things to work past these challenges, and our Global Summit is one of the shining examples. Getting everyone face-to-face builds trust and shared experiences which helps fuels the collaboration when everyone returns to their home locations.

Drawing back to the title, I am optimistic that our teams will build on top of the code, experiences, and collaboration of the summit. We will move forward with a clear view from the Summit, and be able to move into 2014 with more great things in the form of new products, services, or even just great blog posts.

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.

Invading the Product Landscape: A Metaphor

TIM Group development has gone through a major change over the last year. Our primary product has crossed over the peak of the adoption curve, and as a company we’ve been pushing new products for new markets. Our product development habits have had to change from techniques for fighting for market share to techniques for proving that a market exists. The human challenge is how do we move away from behavior that has been successful for the past several years?

One tool we’ve used to help make this shift inside our Product and Engineering teams has been a metaphor: Commando, Infantry, and Police. This metaphor has helped us explain how we needed to transform our product development ways, not because they were wrong, but because we now have a new mission.

While you can follow the Atwood link above (or follow from there to Cringely) to learn where we got our metaphor inspiration, the quick version of the metaphor is to compare a product capturing a market to an army capturing territory. The invading army will first send in Commando forces to secure a beachhead. Then, once the beachhead is established and high value targets are under control, you can send in the Infantry to exploit the the opportunity and take over the rest of the territory. When control over the territory is established, you can send in Police to keep the peace. To draw the comparison, “territory” is the new product landscape itself. First, you establish a way into the market by selectively solving the highest value problems in the product space. Then, with your first visionary customers happy, you can roll out more product features to bring in the early majority and start building out market share. As you gain dominance, you can focus product development more on keeping the existing market happy and building scale.

This has enabled us to rethink the role that we want our Product and Engineering teams to have while developing new products, as well as while sustaining our established core products. We expect different behaviors out of Commandos than we do the Police. Commando Devs and PMs should be ready to react quickly and make trade-offs to get the high value targets as quickly as possible. A new product could fail in these early stages, and we don’t want to be building out the whole product just to learn that the market isn’t interested. Moreover, what we learn building out the early product may help us to “pivot” and focus in a new product direction.

We were able to put a frame of reference around our previous product experience. We were an Infantry organization. We had focused on high efficiency, smooth logistics, and regular pace to keep our product expansion in order. By contrast, with our focus on new products, we need to react quickly (and likely erratically) to take advantage of market opportunities when they arise.

See Part 2 in the series about the trade-offs we have made and how we have been “lean”.