My First Product Failure - Pt 2

In my previous part one of this article, I told the story of my first product failure. This is the second part we continue the story, and try to find out from my point of view why I think we failed.

Before we dive in, we have to acknowledge that this product failed in 1999. As a reference, that was two years before the agile manifesto was even created. In many ways we know much better now.

So to start with I want to give ourselves a break. It just did not work out.

Still, looking back from today’s view point we can learn. There were many holes in our game, so let's open the lid and highlight a few of them.

Where I think we failed

‍Product risk

Arguably our biggest mistake was allowing too much unmanaged product risk. We made too many big assumptions, and we had nowhere nearly enough early validation. We had failure in all areas of product risk except perhaps viability.

‍Product strategy

I believe we targeted a segment too big with the first release. Why did that happen? Because that was the segment the company wanted to make a bet on at an investment level. At a high level that is fair, but what has to happen after that is developing a good product strategy.

We did not break that investment bet down into a sequence of smaller objectives. Doing so would have allowed us to gradually grow a product that can be validated in parts over time. Instead, we assumed the new product would be a fit in the market and just worked off a big list of things we believed needed to be built to target our segment.

I even wonder today if we chose a solution that was designed to be overly flexible in part because we lacked strong segmentation and strategy. That is, an unwillingness to create clear product focus led to a design that embraced keeping too many options open.

‍Lacking product leadership

We did not have a clear product manager in the way that we think of that role today. We had multiple people having those types of conversations, but not in the right way compared to what was needed. As already mentioned for example, we did not have an insight driven sequenced list of problems to solve and we did very little to burn down our product risk.

Making hard calls in time for it to matter becomes harder and more time consuming when accountability is too spread out.

‍Poor engineering practices

Source Safe had been released in 1994 and we used that for everything we built at the company, so at least we had source control. But that was about it on the plus side. We did not have the experience on the engineering side to see what we were lacking. To quickly list a few shortcomings:

• Not enough frequent integration
• No automated testing
• No automated build servers (although, we got a manual one late in the project)
• Not enough care for designing and testing a smooth installation & data import experience
• Not enough performance testing with realistic data or data volumes

Now to be fair, at the time most of these concepts were not even a thing. The extreme programing movement started in 2002 or so and the first unit testing frameworks emerged about 2004. Very few people talked much about build servers.

Computer science classes had trained us very well to understand and apply modern programming practices, but at the time no engineering practices were taught.

Architecture & non-functional requirements

Very early we committed to an over-generalized architecture/design that was innovative and hyper flexible, but that came at a high cost that made the product too complex and caused performance issues. We did not understand how risky this design choice was, and we did not do enough to manage this feasibility risk.

Also, as mentioned we had not given enough design and test considerations to non-functional architecture needs such as performance and scalability.

‍Poor customer experience

We did care about making the user interface user friendly. But we did so as usability trained engineers and business experts, at the level of each view and the most basic navigation between them. We lacked the perspective of holistic product design, where you take into consideration the whole customer experience and integrate design of the parts from there.

We also had too much focus on building a product that was easy to manage on the supplier and customization end, and not enough focus from the customer’s point of view.

We did not do user testing outside the building until having worked on the product for over two years. Instead, we probably were too scared to create a poor first impression by showing things that were not final.

‍People - missing pieces in the team composition

If I had told my younger self this today, I am not sure he would have believed me. But our team composition was not great. Here are some of our team weaknesses.

• No dedicated experienced tester. We had business experts that tested, but we lacked a systematic approach to all aspects of quality.
• No tech lead on the team with experience from building a successful product. We had well educated and dedicated junior devs, but we lacked a hands on frontliner with the experience of having overcome tech challenges at the team and product level and the seasoned judgement that comes with that.
• No usability / design expert. We had people very experienced in the customer’s business, and people very experienced in operating successful products targeting the same segments, but that was not enough.
• No clear product manager. We had people experienced with developing portfolio products for this segment, but they did not make enough hard tradeoff decisions and do enough of the things we associate with the product management discipline today.

What did we do right?

Despite the product failure, we still did do a lot of things right that I would not have changed.

We had great teamwork and built a strong sense of community. We had fun together, and also felt fully committed to our goal.

We were a co-located, full time team with business experts on the team.

We had a good work environment. Team was given a product to build, and trusted to get the job done. Our environment was very supportive.

We had picked good technology, and we were able to master applying it. The tools were there to build something great.

We had people who really understood the business, and the customer domain. That was a strength.

We had stable funding. Yes, there were conversations about runway, budget and there was pressure to get the product out. But by and large, the company was committed to follow through.

We believed we could do it, and we embraced going for it without much fear or hesitation.

So what did I learn?

This experience became a big shaping moment early in my career. I learned that you can work hard and do good work and still fail. I learned that I did not know enough and probably people around me did not know everything that was needed either. I realized I had to search far and wide to find the best sources of practical experience, and apply them first hand.

So in the end this failure started my journey of finding successful practices, and develop the skills needed to succeed with tech products. For that, I am very grateful.

I am still learning, by the way.