Products or: How I Learned to Start Worrying and Fear the Services

Within tech, I've constantly been surprised by the religiosity surrounding product development. For a long time, I didn't understand it. In fact, it wasn't clear to me why selling products was strictly better than selling services. My career started at a company that provided a fusion of products and services, as many large enterprsie software companies do, and especially when I started at the company, it wasn't clear why providing products was such a focus for the company. In fact, when I joined, it was very stressful to be on the product development side of the organization - things seemed decidedly murkier when trying to build products than when trying to fulfill contracts.

However, there are a number of reasons that traditional product companies are so desirable. Some of these are purely financial - product companies have a much higher capacity to generate profits than other companies. Others are, however, much more cultural. Product companies bind groups of people together with an evangelical furor that rivals some of the worlds most popular religions, provide clear focus as a company grows, and allow people to concretely see what an organizations does.

I remember very clearly the first time I talked about the value of product development with my boss in 2014. I was working on a failing product at the time, and felt dejected about our lack of progress. We had worked hard, but the product we had built was useless. It wasn't because we had failed to build something, but rather because we had built the wrong thing. As a product manager at the time, the responsibility for this directional failure was mine, and I was frustrated and asked him why we focused on products when the expected return on services felt so much higher. His response stuck with me, and focused on three main components.

Firstly, product development has a much higher failure rate than providing business services. Most product development efforts fail, and many of them fail spectacuraly. However, this failure rate still doesn't change the fact that the expected value of product development is almost always higher than providing raw professional services. Despite the extraoridinarly high rate of failure, successful products are incredibly valuable, and therefore often dominate any rudimentary expected value calculation.

This value comes from a combination of two traits, which I call horizontal and vertical. Horizontal value comes from a product's ability to increase efficiency. These type of products help businesses do the same thing that they've always done, but faster. This, in turn, reduces the cost of revenue, and allows the business to generate more revenue with the same number of people. Vertical products, by contrast, open new lines of business - they allow companies to increase their top-line revenue numbers. In this model, Ads at Facebook would be a vertical product while the HipHop Virtual machine, would be a horizontal product.

In either case, though, products produce lasting results; once developed, they can continue to provide value for years either by reducing expenses or increasing revenue. This, in turn, makes them assets for the company despite not requiring additional investment.

So from a financial perspective, product development is essential. In the next post, I'll spend some time talking about some of the other ways that products can provide value. 

Small Wins

Going to an Ivy League school, you're trained to imagine that a successful professional career involves tackling big ideas and changing the world in grandiose style. In my four years of professional life, however, I've come to realize that the big wins that make headlines are often not obtained through sheer force of will and intellectual brilliance. Instead, high-level success is the emergent property of low level discipline and tactics. In this time, I've come to realize that tactics is a necessary, although not sufficient, component of successful strategy. This may seem obvious, but the American educational system often downplays the real work required to manifest actual change. Inside the academy, people spend their time primarily talking about what to change, but spend very little time thinking about how to effect that change. Policy is a much more acceptable research topic than politics.

As a result, I didn't have much operational experience going into my first job. When I showed up, I was surprised at the sheer volume of tracking, task management, and project management that I was asked to do. I saw this as a gross inefficiency and spent many hours trying to avoid it rather than excel at it. In particular, I think that I had an intuition that this level of process was an indication that the organizational structure wasn't correct - with a better structure, wouldn't most of this go away?

Having watched many, many projects succeed and fail, however, I can safely say that having a baseline level of operational ability is a necessary, although not sufficient, prerequisite for success. While small teams (<5) can thrive without structure, as the size of a group grows, the more important it is to have a de facto project manager.

I think that this point, that small wins combine and compound to create big wins, has one other interesting result, which is that the importance of a task is not always directly related its intellectual difficulty. Indeed, task management is often not the hardest thing despite the fact that at times it is the most important. Taken further, I think that this also reflects an interesting truth about founding businesses or building successful products: the best product or company is often not conventionally hard - indeed, with everything equal, an easier product is probably a more valuable product to build than one that is difficult. Sometimes just doing something, rather than thinking about that thing, is the best way to create something that lasts.