Show all posts
5 years ago

Product Software Development is a Marathon

Most people like short things: short tasks, short emails, learn-how-to-program-java-in-24-hours books, lose-weight-in-a-month video guides. Modern society is cursed by impatience and time pressure. Information flows hit us from all sides and we just can’t resist. We spend more and more time on shorter and shorter things.

Software development demands focus. You can’t create anything significant hopping from one thing to another. That is obvious. Less obvious is that product development demands patience.

Service development is different. In most cases you have a project with a visible end. It may be a year long, or even several years long. But still project will be completed someday... Or abandoned. Most service products are sprints. Clients pay you money and they want to have something as soon as possible. They radiate the impatience. They set deadlines. They resist to invest much into good engineering practices like automated tests. Yes, you negotiate all that and sometime with a success, but still it’s quite hard to sell a great development process to the customer. So you rush, cut corners, drop some good practices to save time and argue about change requests. Agile approach helps to solve some of these problems, but you still feel the constant pressure. And rush anyway.

This strategy doesn’t work for product development. It takes a decade or more to create a truly remarkable product. Constant rework, constant improvements, constant polishing and learning. You fail, learn something new, improve things and move forward. It just can’t be done without patience.

Suddenly you understand that great thing takes time and it changes your attitude. You learn how to run with a steady pace, maintain energy level and endure the race. In a sprint you have no room for any mistake. Even a little mistake will cost you huge. In a marathon you have time to fix problems and still win.

If you are in a product development business, I can give you several advices:

  • Learn how to learn. This road takes many years, you need knowledge to solve problems and invent things.
  • Learn how to wait. It is so fucking hard to me. Sometime I feel enormous pressure to speed everything up and run at a full speed. But I realize that it will drain all our energy and development team will be exhausted and washed out. We’ll start to lose people. Morale will go down. That’s not a viable strategy.
  • Embrace re-work. Most likely you will have to re-write some parts of the system 3-7 times in the next several years. You should be ready to do that. Re-work is good. It makes things better.
  • Ship early. You may think that now I’m a 100% perfectionist who will kill for the 1px design mismatch in a latest release. That is far from true. I like to ship things as early as possible to some closed group of customers at least. For example, we are working on v.3 of our product during the last 15 months. It is still not public. However, we had first users 9 months ago. Currently around 600 people from 100 companies are using v.3, we have constant feedback and make improvements based on it.

Remember, that most people can run a 100 m distance, few people can run a marathon.

  • Martin Burns

    This is spot on, and goes a long way to explaining that the industry is inappropriately projectised (as opposed to working in a standing process) and why that might be.

  • warehouseIt

    Sent this artical to all our programmers and Directors – great way to end the week with some humour

  • David Brakoniecki

    There is a lot of good advice in here but I’m not sure about this:

    “It takes a decade or more to create a truly remarkable product.”

    Really? Cast your mind back 10 years ago. How many great products or opportunities to create products would look like what they do today from what was known 10 years ago?

    Could a mobile strategy for business that didn’t have Blackberry at its core even have been dreamed up 10 years ago? Again, the advice is great: Ship early, Learn to learn and refactor your product as circumstances change.

    But, was starting your product 10 years ago in these sectors any advantage over starting 5 years ago? Or, 2 years ago? I doubt it.

    Timing is everything and different markets have a different cadence. It’s pretty important to move at the speed of your market. Or, someone else will.

    Another observation: no new business or start-up has 10 years to find product-market fit and commercial traction so does that mean only established businesses can develop great products?

    And, the reverse, was it only the last 5 years of google’s development of search what made it a great product? Most people probably have no idea what the last decade of search algorithm tweaks at Google have done. The product was great before that …

  • Katherine Lazarevich

    You are spreading your experience to all product development industry. It’s too ambitiously. A lot of product development companies are dealing with deadlines because of:
    1. budgets
    2. competitors

  • Michael Dubakov

    1. nope
    2. nope

    ALL product companies have budget constraints and competitors. It does not mean that there should be deadlines.

  • Michael Dubakov

    Sure there are exceptions. We are walking on a thin line between good and great products in this discussion. I agree that product development pace should be comparable with market pace. I don’t think that you can polish things forever. That is obvious.

    However, I believe it really takes about 7-10 years to create something great. For example, we had acceptable product in a year of development. We still don’t have great product after 8 years of development, but I really hope that v.3 is a huge step forward.

    P.S. By Great I assume #1 on the market.

  • indigo777

    I guess your reaction is the flip side of the bulleted “how to” lists :). Such posts should rather be treated purely as experience reports. everyone is free to make conclusions for themselves. If you noticed, I try to avoid “how to’s” altogether in my articles. intelligent people will learn their lessons one way or another, and Michael’s post is thought-provoking.

  • stuartleitch

    There are deadlines, but they’re like the milemarkers on your marathon. There’s very little point in sprinting up to one, it just makes getting to the next one tougher

  • Michael Dubakov

    Yes, that is a good point

  • toolsjournal

    Spot on. It took a year for us to realize this point last year enhancing
    my little website :). The more i do, the more i realize that
    deadlines are infact a distraction to delivery. What really works is a continuous flow of what you can achieve at regular intervals.

  • Joshua

    Like many things in life, it’s a paradox: just as much a sprint as it is a marathon…

Try for free

Account url: *
How many people would be using Targetprocess?
  • Myself
  • 2–20
  • 21–100
  • 101–1000
  • 1000+
By clicking Continue you agree to our Terms of service and Privacy policy