Fighting My Instincts

Project management is about combining what’s now with what’s next. A good project manager knows what status the project is right now, but also has a vision about where the project needs to go. At some point, the vision is transformed into a series of features and each feature is described as a list of tasks, that someone on the team needs to do.

Entrepreneurship is all about vision and getting there. Experienced project and product managers understand that there is a very long process between having an idea and having a product. Developers don’t always notice this. We work in smaller chunks. We tend to dive real deep into much smaller ponds. We have greater understanding of detail, but less understanding of the bigger picture.

You have to stop thinking like a developer

Building a startup is a process. It starts with an idea. The idea has to go through market validation. Do people want what you are making? How can you tell? Only then you can start developing. In many cases, what fails a startup is not the technology, but the product-market fit.

I’m a developer. I think like a developer. My instincts tell me:

This is a really cool piece of technology I’m thinking of. If I write this software, I bet everyone will love me and shed me with riches and prestige and hot chicks. RESTECP.

My instincts are stupid. And shallow.

You will not get rich by writing great software. You will get rich by writing get software people want to buy. Or at least, software they want to use. Jeff has said it better than me:

A smart software developer realizes that their job is far more than writing code and shipping it; their job is to build software that people will actually want to use. That encompasses coding, sure, but it also includes a whole host of holistic, non-coding activities that are critical to the overall success of the software. Things like documentation, interaction design, cultivating user community, all the way up to the product vision itself. If you get that stuff wrong, it won’t matter what kind of code you’ve written.

You have to start thinking like a product manager

The product manager is the person responsible for the transition between what the market wants and what the product is. There are many different approaches to product management, but one of my favorites is that of Eric Ries. Eric teaches a type of product management that is based on rigorous scientific methods. I love these methods because I love numbers.

Here are the pillars of the Lean Startup:

  • Progress is Learning per Dollar. You are looking for a product-market fit. Each dollar spent, should get you closer to product-market fit. Don’t measure progress in features and lines of code. Measure progress in the maximum amount of information you can gain from each dollar. This means:
  • Measure. How is my product performing in the market? The best performance indicators are concrete. How much time does a user spend on my site? What percentage of people downloading my demo actually buy the complete version? What is the Life Time Value of an average customer pay? How much does it cost me to get a new customer?
  • Split Test. Does this change improves the performance of my product? Have half your users use one version, and half use the other version. How did performance compare? There are simple mathematical tools for hypothesis testing, and they are highly recommended. Make small changes at a time, and measure all the time.

These ideas may be easier to implement for a website, however, the practices of the Lean Startup are translating into other fields as well.

I am fighting my instincts.

I am a developer. My instincts tell me I should write the code, right now! Every time we talk to a potential customer or potential investor, I think, “screw this. I should be coding. If I were, the product would be done, and they would all buy into it in great quantities”. But we still hear “No”, more than we hear “Yes”. And sometimes we hear a “Maybe”, which could be a “Yes”, if we understand the product-market fit better.

We still need to find a way to get “Yes” all the way through, before we invest too much in code that does not improve our product.

  • Fight your instincts but don’t kill them off. There are healthy approaches that take the best of both worlds, namely the variations of Release-Often-Release-Early, the MVP (Minimum Viable Product), etc. These let you leverage your thirst for quick coding. Build something as small as possible, that can bring real value to customers – but also that can bring real insight to you, to teach what works and what doesn’t. Then, you’ll be smarter for the next iteration.

  • That’s true. I’ve been preaching release-fast-and-often for years. However, most of these practices apply best in the web, where there are millions of users and you can actually experiment over time.
    There are some products where the market structure is against you.
    For example, if you have an idea for a high-end product that will help the IT managers of a Fortune-100 company, it is better to ask them what they want. It’s unlikely that you can ship a product that is mature enough for these companies, with a “release-early” approach.
    As David Weekly pointed out in his lecture at the lean startup circle: if you plan to sell a product at $10K a piece to organizations, you can expect fewer sells and higher acquisition costs. it will take you very long to collect information even if you release fast and often.

    You know very well that doing the leg work is extremely important. There’s time for release fast-and-often later.

  • I think the approach you suggest works well when your product solves a physical, measurable problem, like saving time/money, increasing performance, etc. Than when you come to your customer and ask him “would you pay X for Y% increase in performance”, the customer can give you a straight answer from which you can learn something.

    This approach won’t work though, when your product is supposed to solve a problem that the customer is not yet aware of. I don’t think that products like Facebook or Tweeter could be built that way.

  • Facebook was first deployed in one collage, and then in another and another. Each time they learned, and fixed, what was needed, so that next time will be easier. This is classic Lean behavior. They had a minimal product, they deployed it fast, and with small groups. They iterated a lot. They still do.
    The Lean Startup approach is meant to deal with situations where the problem and the solution are both unknown. The Minimal Viable Product is meant to teach you whether or not users have this problem. They may not know it yet. That’s why you build something very small and very fast, and try.
    If the solution is known, Waterfall Development works best.
    If only the problem is known, Agile Development works best.
    Lean is for situations where even the problem is not defined.

  • You are talking about the situation when the problem and the solution are not known to you – and in these situations lean approach is very sound. I am talking about the situations in which the problem is not even known to the customer, in other words, the customer has not been aware that there was something missing from his life.
    Of course getting the product to customer and asking him “do you like this” is always a good idea, I only suggest that in some cases the customer won’t guide you to the perfect product – you’ll have to have your own vision. The customer will only be able to passively appreciate and “like” or “dislike” your product.