It is not a secret that there is a gap between engineering and business worlds. They speak different languages, and they are often in conflict. Switching sides and going from engineering to product management, I was looking forward to see the world from business point of view. I was sure that I’ll become a lot of insightful information. The kind of information, that might help to bridge the gap the between engineering and business. Today I want to write about the first piece I’ve learned.

This Fall, I was walking together with my father, who is an electrical engineer. We were talking about his and my jobs. I’ve asked: what is your typical feedback delay? He was, like, “what are you talking about?”. I’ve explained: say, you have a circuit, and you need to improve it, and at some point of time you snap your fingers, because a promising idea has come into your mind. So, you first change your drawing, re-calculate and simulate the new circuit in software, then you solder the changes in your actual physical developing board, then you turn it on, fix soldering problems, ensure it works, measure its parameters – and now! Finally, now you know if your idea was good or bad. So, what is the typical time span between snapping your fingers and knowing if the idea was good or bad?

He responded calmly: well, it’d take a couple of days. If everything goes well, perhaps one can even make it in one day.

I was shocked. I’ve expected something in range of several hours. I’ve said: as a software developer, I consider feedback delay above 5 minutes to be hell and absolutely inappropriate. Longer delays will surely knock me out of “the Flow” state of mind. This means I would become several orders of magnitude less effective. My typical feedback delays in web development used to be 2 to 15 seconds. In the TV set software development, I had initially delay of 40 minutes (especially when a full re-build was required), and I have invested a lot of energy to reduce it to 20 seconds in the best case, and to (barely acceptable) 6 minutes in case kernel code had to be re-compiled and flashed. I have also explained to my father, that there are some newest state-of-the-art IDEs in the web development that achieve the feedback delay below human-perceptible fraction of second, and the people who have used them say that it would mean another order of magnitude improvement in their efficiency.

My father was bored. Reducing feedback delay never occurred to him as something important. Most of the time, he told me, he would require some components that are not available on the internal stock and have to be back-ordered. This is where the couple of days delay comes from, he said, and you just switch and do something different meanwhile.

I’ve just started as PM back then and I thought, this might be a useful advice. The way the lean PM works, at least in theory, is very similar to any research, including software development or engineering. You snap your fingers, because you have an idea how to improve your product. You spec the idea, shape it together with all stakeholders, and then you kick-off the development project, and the idea will be developed, and at some point you get it for testing, and the software will be bugfixed, and at some point you’ll release it live, and users start using it, and you wait some more to gather enough data for it to be statistically relevant, and you analyze the data, and finally learn if and how your idea has worked.

I knew, as a PM I couldn’t have feedback delay of seconds, minutes or hours. I was thinking about weeks. So I’ve figured out, I’ll just learn how to run several ideas in parallel and switch between them to overcome the necessary feedback delay.

What I wasn’t prepared to, is the world where my feedback delay might be up to 6 months, or even longer.

Up to six months.

This is 180 days, or 1440 hours, or 86400 minutes, or 5184000 seconds of waiting for idea to be tested.

Man, people change significantly in 6 months. The world changes significantly too. By the time my idea will be released into production, I might be fully disconnected from it, because I’ve learned and changed so much in the past 6 months.

Also, put it in this way. As a software developer, I usually need around ten feedback loop iterations to develop even a simplest thing (like additional simple checkbox on a web form). I didn’t become smarter switching to PM, so I supposedly would still need my ten iterations before I find something useful. Ten iterations a 6 months each, would mean investing 5 years of life, just to find out one small working product!?

Luckily for me, this math is irrelevant. Every hour I spend on specifying, means one day of work for designers, and perhaps one week of work for several developers. Performing ten 6-months iterations to find product/market fit will most probably be more expensive than any expected earnings from the product. So, the program will be terminated much earlier.

This all boils down to the following equation:

P ~ N = Inv / Ci

The probability P of finding a reasonable product is proportional to the number of iterations N, which is equal the investment Inv we are willing and/or able to make for this program divided by average cost of a single iteration Ci.

In reality, this equation is a bit fuzzy, because Inv isn’t strictly speaking a constant, but the overall factor relationships remain. Which will inevitably bring us to the point: if we want to make everything we can to improve our chances of finding a product, we have to reduce iteration costs.

I’ll repeat we last sentence in the engineering dialect: in the beginning of the new product, we have to write code that is just (barely) good enough. That is, not commented, not unit-tested, not necessarily being able to handle more than a handful of users simultaneously, not always readable, not maintainable in the long term, handling only 80% of all cases (i.e. not handling any corner-cases properly), maybe a little slow, and perhaps eating a gigabyte of RAM for trivial tasks. But, written as quickly as possible, and providing the perfect user experience (for the 80% of use cases).

To put it in another way, we have two choices: either work for six months producing a single release with a cool source code, which will be then thrown to the garbage bin, because we didn’t manage to find the product. Six months of life wasted. Nothing gained. Or, work for six months producing twelve releases of good enough source code, but having finally found a working product. And then we can gradually improve our source code. In a couple of years, nothing will remain of the initial code the new product was based on, and we all could be proud of having created a new product.

Back in 2006, my choice was clear: never compromise on quality. I was so full of this shit every software engineer is being fed in the university and in the most of books – the holy grail of craftsmanship, and you have to be proud of the quality of your work. I overestimated complexity of coding, and underestimated complexity of marketing and product. I used to say, “you’re business guy, you have to ensure your product idea works even before you bother me coming with a kickoff meeting. Just like I’m responsible for proper implementation, you’re responsible for proper business value.”

In 2006, we’d got a first project involving some new technology. And the business guys had told me that other similar projects might come. Therefore, I took over the role of a technical product manager: already in the first project, I’d extracted parts that might be reused, and implemented them in a generic way, laying over the foundation of the future product. I was already proficient in creating reasonable software architectures quickly and efficiently, so that it didn’t take too much additional time and therefore went successfully.

When the second customer with similar requirements appeared though, two things happened at once. First, I’d discovered that the first version of my product, however generic, could not handle all requirements of the second customer. This was expected. From the beginning on, I’d followed the YAGNI and KISS principles to avoid creating a mega-configurable monster that could still fail to be generic enough, but would require a lot of efforts up-front. Instead, I was planning product development in a modern, agile way: start with some reasonable point, and iterate, continuously extending the genericity of the product, driven by actual customer needs, until upcoming projects can be implemented by merely reconfiguring the product.

What was totally unexpected though, was that I was fully used in another project having tight deadlines, and neither I nor my management could afford delaying it. In my opinion, the situation was clear: because I’m unavailable, we should delay the implementation for the second customer, or even turn him down and wait for a next possibility. But the business guy who had owned the second customer decided differently. He had just copied the source code of the first project into another folder, changed the code in the simplest way possible to satisfy requirements of the second customer, and rolled out this web app. (did I mentioned this business guy was also an engineer?)

This had naturally lead to a heated discussion between us. My points were:

• He had missed an opportunity to improve our baby-product.
• He had created a second instance of a similar software, which had to be bugfixed and maintained too.
• Evolving a generic product step-by-step out of customer projects was a technically challenging non-trivial task I was happy to perform. But if our strategy was rather copying source code of a previous project and changing it from customer to customer, such an experienced engineer like me was overqualified for this task and the business guy should go find some junior developer and stop wasting both company’s resources and my own limited lifetime on this product.
• The mess he had created was not worth of those some thousands of euros he could earn from the second customer.

That business guy was shocked and had just said that he didn’t and doesn’t see how he could do things differently.

From my current perspective, I suppose he was just carefully testing the waters: is there a feasible market for a product? This was perhaps a communication problem as other business guys had told me to work on productization, but actually, there was no point to invest into software productization unless there was some objectively measurable or at least subjectively perceivable market potential. He had one data point, and was handling the second one, and perhaps after the third one we could see where it was going. When we were still testing the waters, the only things that were valuable were time-to-market, and as little efforts as possible.

And here is the key learning of this story: we’ve never got a third customer.

This has resolved our tension in a natural way. But suppose we’d have gotten another customer; what were a proper strategy for me, knowing everything what I know today? I didn’t do much wrong in the first project. Well, I had introduced some not very necessary admin UI, wasting a day or two of efforts, but most of the time, this was just good enough code with focus on time-to-market. The issue with the second customer wasn’t a problem in my strategy, but rather a coincidence (my unavailability). Therefore, I should have continued to evolve the source code of the first project, just barely enough to be able to support requirements of the third customer – basically, proceed with my agile strategy, leaving the solution for the second customer aside (and accepting it, and counting it as necessary evil).

If the things went well, eventually, we’d have had a continuous stream of new customers wanting our baby-product, and this would have been a proper time to come to the business guy and discuss if we’re going to invest some more into the product itself, what our main features are, what about building and training a team to maintain the running web apps, what about change and release management, public versioning and changelog, cloud solution, marketing activities and all the other stuff pertinent to slowly maturing products.

The reason why we haven’t got a third customer: there was almost no market for it back in 2006, and none at all today. As of today, three huge corporations have each a free-to-use product, rendering our idea useless.

So, to summarize, when working on a new product, it might be useful to see it in the following phases:

1) Market Exploration phase (refer to the slide 26). Here, develop as quick as possible. You are allowed to develop dirty. You’re also allowed to develop less dirty – but only if this doesn’t increase development time measurably.

2) Productization phase. Here, some more or less dirty code has to be gradually converted into more generic one; new features are mostly developed in a generic way, but still, the code has to be of the good enough quality, that is, being barely able to handle requirements.

3) Maturing phase. We start focusing on source code quality, scalability, security, performance, maintainability, processes and so on.

Hell yeah, I know they say that security cannot be added, it must be built from the very beginning. Or, scalability cannot be added, it must be built from the very beginning. And, and, and… Now this is a challenge of course, and I’m interested to write more about this topics in the future. But yet again, if you spend time for those properties in the first two phases, you’d probably just waste your time and the time of your team on a dead-born product.