12 mins read time

Technology Product development is incredibly hard. So hard that no more than a third of tech firms try and attempt it. Within the ones that do, very few get it right. As a founder if you are debating the software product vs services startup call, what should you be aware of?

Why the big fuss? The short argument in products vs services startups debate is that products are harder. They are easier to scale and easier to exit than services, but harder to get right. Services get to self financing stage quicker. Clients are happy to pay for work done. Products need a longer runway. Products require a build and test cycle that needs to be financed before customers sign up. Product teams also require different skills and mindset compared to services shops.

Why is that? After all technology is technology, all of it should be difficult, or all of it should be easy. Why does product development get all this press and coverage about being difficult?

I cut my teeth with outsourced technology services in early nineties serving customers in US, Europe and MENA region. Then spent the next twenty years building and working for product companies in the same regions. Here is a quick review of product vs services startup debate from a startup founder who has done both.

Product development and management cycles.

Like everything else in life good product development is iterative and driven by marginal improvements that compound over time. It takes patience and a few cycles to get it right. The cycles and times vary from industry to industry, region to region.

There are two key elements to master for one to become a product ninja. The first is the underlying domain applicable to the product you are trying to build. To master a domain takes years of practice and education. Mastery tends to be a science with no instant get. There is a sequence involving education and apprenticeship that cannot be shortened or short circuited.  The second is the process of building and growing an idea to its true commercial potential. This build and grow expertise is part science, part process, part art.  To become good at it, you have to practice the art.

Relationship and trust, not products.

Good product development teams are like General Practitioners (GP) – the good old family physician your parents used to take you when you caught a bug or came down with a fever.

Good GP’s age well. As they grow old the range and diversity of their experience makes them increasingly valuable. They are not just physicians but also historians and record keepers.  They treat multiple generations of patients from same families. The treatment and cures they prescribe are not driven by just protocols but are customized to their read of your entire family history with them.

If you forget to tell them you are allergic to Levofloxacin, they already know your mother doesn’t react well to this strain of 3rd generation antibiotics and you probably carry the same gene.  GPs, wherever they still exist, build trust levels with families that are hard to beat.  While you may question or challenge a specialist physician or surgeon on his recommendations, you do what you are told by a GP who has been treating you since you were wearing diapers. Not doing so may result in a public scolding by your parents irrespective of your age and your stature.

Product teams are like GP’s because they have history with the codebase (they know where the skeletons are) and customer use cases (they know how it works, what makes it break and what pisses off customers). This relationship exists because they have been working with the codebase and product use cases since they both started wearing diapers. Like good GP’s, good product teams tend to know more about underlying domain than customers and have the final say on solving design issues or implementation challenges.

Skilled technology resources employed by technology services shops that charge by the hour are like surgeons and dentists. Their value is a function of their physical ability to work long hours and their skill levels with current tools. There is no history or relationship with clients or codebase, only transactions.   You are only likely to get two knee hip replacements post forty, spread over twenty years. As a surgeon there is no need to build a relationship if I am going to see your joints once every 5 years. You won’t even remember the encounter because you would be under when it happens.

Compare this to a GPs that averages 4 visits a year from diapers to diapers from the same patients.

Product development is hard because relationships are hard. Product companies don’t build products. They build trust and relationships. Great product companies honor that trust investing time in understanding the context and by seeking and adding value in everything they do. They deliver value first to make the ask, trial, close cycle easier for their customers. Their customers appreciate it by becoming repeat buyers and evangelists for their brands.

Look at any product that gives you a case of instant want. What did they do to make you feel that they designed this product for you and just you? Context, trust and value.

Services companies may build relationships over years with repeat customers, but such relationships rarely survive.  Customers teams and project managers change every few years. With the change, vendor preferences, budgets and cost allocation also change. Relationships rarely survive such realignment. Smart services companies understand this and price using a transaction model that work off a single engagement. Any repeat work is a bonus.

Build, break, rebuild, ship cycles.

For a product company, build cycle start with the assumption that we are wrong and whatever we put together in our first few iterations will be taken down and redone, again and again. Each cycle running faster than the one before till we converge to a solution that works. There is no designated endpoint or terminal specification, only convergence. We can’t ask are we done yet? Have we arrived? Is it over, can we go home?

Think about this for a second. This level of ambiguity and chaos may work for a two men team but how do you scale it to two hundred employees. How do you handle the rejection or stress of being wrong repeatedly? Most technology teams can’t handle the transition from detailed specifications to ambiguous statements. Where is our safety net?

Turns out there is none. For product shops there are no services clients, no sugar daddies to cover monthly expenses. If we are not careful and not right occasionally, we don’t get to eat, feed our children or pay our bills.

Refinements to the build come directly from customer user experience. Sounds easy. It isn’t.

How many customers do you know who are willing to fund, finance or donate time to your big product development push? What’s in it for them? Remember that last time when someone stopped you to ask a few questions on a survey at the supermarket or hyper store? Remember your response?

Product teams are also good at eliciting feedback and input from customers without really seeming to do so. Rather than asking, they observe. Rather than being explicit, they run the feedback loop in the background where it isn’t visible.  Instead of being told what needs to be done, they lead customers to the path that delivers the most value. Remember, we know more about the domain and the business than the customer.

Listening to customers and devoting ourselves to their needs is difficult for most founders. We are not good listeners.  Or good at admitting that we missed the all-important signals. We find it difficult to believe that we were wrong and someone else, especially a customer, could be right. There are always exceptions, but founders are founders because they like doing things their way. Aligning that thinking to someone else’s perspective is a challenge for most.

Finding talent and teams that know more about the business of customers than customer is also an issue. You can’t find such talent. We have to invest in their training and their growth, much more than customers invest in the growth of their own resources.

For a small technology business, these are impossible asks. The universe has to realign itself in ten different ways before you can meet them. Opting for services business is often a much easier choice.

Three months to ship.  

A good build-ship-break-rebuild cycle for features and minimum viable products is 3 months. Shipping a new release in 3 months give us the discipline to build in 30, test in 30, and launch in 30 days. Works for features, books, content, enterprise software, documentary shorts, animated films, e-learning and games.

A 30 day build and ship cycle means that quality assurance and testing needs to be integrated at the developer level. Product teams have quality assurance groups that enforce daily builds and daily regression tests. Developers don’t handover the build, they run the automated regression tests. If they break the build, they can’t go home till they have made it whole. Quality assurance isn’t a function in product teams, it is a way of life.

There is also this bit about complexity. We learn to balance features with affordability, ease of development, relevance to our segment, usability and time to market. That is six dimensions. Keeping them straight in our head, much less optimize them, is a stretch, if not a challenge. Product shops acquire optimal thinking models with experience. What would give a technology services team a migraine, is a simple queuing theory formulation for them.   

With our limited resources, three months is short enough for us to not over commit or go overboard with features or build quality, long enough for us to get just one feature right. If we are well funded, it is difficult to break the bank in 3 months. If we have funding for a year, we get three shots to get it right.

Quite often we shoot for markets that don’t exist when the product development effort is sanctioned. But if we are right, we are there waiting in the shadows with the right product as opportunity emerges out of hyperspace.

New Product pipeline.

Our product cycle is determined by shelf life of products in our markets. Enterprise software is 4 to 10 years, banking and financial services is longer as long as we keep pace with regulation;  PC games, 11 months; mobile games, a blink of your eye. 

Which means we can never really rest. Our products fade out with regular frequency and must be replaced. We can’t have only one, we need a portfolio. A supply of fresh ideas, always churning, making, validating, testing, launching and rebooting.

Do you know what that does to our heads?

We look at everything around us with the product lens. Teams, talent, process, funding, marketing, skill set, vision and vacations. We can’t even watch tv, listen to music or read a book without linking and extrapolating trends to our product space.

Imagine training for a marathon for a full twelve months. Day in day out, every weekend. Imagine finally running it on the big day on a crisp wintery morning, dying on the road at the halfway mark, landing in the hospital for dehydration, cramps and foot trauma.  

Then willingly starting the training cycle again on Monday, preparing for the next big one. 

You need to be a psycho to survive the pressure, to live with it, to enjoy it. If you are not one at the beginning, you will be one at the end.

You don’t scare me. Tell me how to build a product focused startup

Okay. You asked for it. Here is my checklist.

  1. Product teams cannot afford to live in bubbles. They can’t shelter themselves from the real world. The only way to avoid anaphylactic shock is to stay connected with reality. Our quality of people, our code, our platform, our features, nothing matters if we can’t breathe in the real world or our products can’t survive first contact with customers. How do we survive first contact with customers? We get them into the product cycle as early as possible. How do we do that? We ship imperfect products. We ship them earlier than anyone else. We work harder than anyone else to resolves issues and problems when they come up. We find customers who are ok with stuff that breaks occasionally because their other alternates are more painful than ours.  
  2. Products companies learn to do difficult and hard things early. Products are hard, why make them harder? We find problems that are difficult to solve and relevant to our customers. If they were easy to solve, everyone could solve them. Because they are difficult, it gives us breathing room before the competition can manage to catch up.  People and organizations that can reliably and consistently solve difficult problems are incredibly rare. Once you join the club, word gets around.
  3. How do we solve difficult problems? We break them down into smaller problems. Problems that we can crack in our 30-30-30 build-test-ship framework.  To do this it is important that we have access to inhouse domain expertise. You can’t build a fusion reactor without access to resources who understand fusion reactors. Product shops are often centered around founders or advisors who have spent time in the industry, have exposure, experience and credibility and understand what needs to be done.
  4. Difficult problems also extend product shelf life. No one wants to rock the boat by changing the semiconductor magnetic containment unit on a plasma fusion reactor once we get it working after four decades of research and development. What if in changing the magnets we break it and it won’t start again? Best not to touch it and just let it run. Or let the experts handle it.
  5. Product teams aren’t afraid of looking, acting or being stupid. Fault and failure tolerance are strong in them. We can make mistakes and not get fired, because it is in the DNA of our organization. We plan our failures, fail fast and degrade gracefully.
  6. We also invest time on learning from our mistakes. Mistakes don’t go into the dustbin; they go to the lab where they are dissected to death till they have nothing left to give.  The right kind of stupidity is underrated. One where we don’t do the safe thing, but take the untried, untested path. Not because of a dare, but because we think we would find something useful or of interest on that path. We can’t breed it if every single misstep leads to a witch hunt.
  7. Good product teams are never stationary, they never rest. There is always something in the oven.  This is a different kind of talent, one that can never find peace at rest.  One that never settles for what’s on the table but pushes for the slightly better, slightly faster, slightly cheaper, slightly easier to work with, edition. Over a decade, the marginally better add up.
  8. Which means the best product teams are self-aware. They understand what makes them tick and what makes them fall apart. They know what they need to fix and change. No one tells them what is broken. They are already aware of issues and challenges. They don’t drop bandwidth on denial. They understand it well enough to replicate and propagate it across their organization.  

Do such organizations really exist? They do. I ran two of them. Still running one. But I wasn’t the only one. There were others too. They all have one thing in common. They all manically believe and follow the same mantra. Don’t be good, be better.

Even marginally better, but better.

All this is fine and well, but where do I start?

You could begin with reading. That is just for warmup. Pick up or find a copy of Microsoft Secrets by M A Cusumano, published by MIT Press. A bit dated since it was first published in 1998 but still relevant. It walks through Microsoft’s product evolution. Also follow Glen L Urban, an MIT professor who has been writing about product development before I even started working. Books and research papers over clickbait online.

The best possible start for a services shop is to “productize” their service. Automate components that could possibly be pushed out to customers or managed by new trainees. Look for areas where customer input or control improves user experience. Let them have it. Build it and hand it over. Put controls in place so that they don’t shoot themselves in the foot and beef up support resources to provide help when they are lost. These are low cost interventions that begin to change the character of your organization from a services shop to a product shop.

If you are still working as an employee and haven’t taken your final stand on the startup corral, pick a product shop over services. Next to building your own products, seeing others build them to is still better than just reading about it.

If you can’t do either of the two, take a small concept or idea, wrap it in a product concept it and ship it. You don’t have to find and sell it to a million customers, a handful are fine. Delivering a service and shipping a product are two very different experiences. Once you get started, you will notice how your approach to design, building and shipping code changes. Rinse and repeat with something more complex for your next round.

It generally takes 3 to 4 iterations or reboots for a product idea to converge to something that sells. In founder speak we call it finding product market fit. So don’t bet the bank on your first product getting it right off the launch pad. Hold back a little for the next 4 to 5 iterations that are likely to follow. Be patient. In order to be fast, you have to first learn to run slow. Don’t beat yourself up too much if no one buys, pay attention or acknowledges your work. Keep on marginally improving your work product. In the beginning you are just an apprentice trying your hand at the art. It’s a long road to becoming a master. Patience and practice will serve you well.


Faizan Siddiqi (@faizansiddiqi) and Jawwad Farid (@rebootdude) run tweet storms and threads every morning 8 am and 9 am PST. Topics and themes vary but the focus is on desi founders, startups and stupidity.

Their model is simple. They pick a topic and tweet the first ten things that come to their minds relevant to that space. Tone ranges from rants to philosophical and romantic advice. Sometimes relevant, always interesting.  

This morning the tweet storm covered product development and absence of product led growth in conventional businesses in Pakistan (Faizan Siddiqi) and the reasons why product development is hard for local technology shops (Jawwad Farid). The note above is summarized from their twitter stream which are shared in original, under suggested reading below.

Also our apologies for the times where we sound like a cryptic mash of Kungfu and Jedi Masters, the worst possible of all combinations from Kill Bill, Kung Fu Panda, Shaolin Soccer and Star Wars. We need to stop watching these movies.

Suggested Reading

  1. Three lessons on innovation for startups
  2. Premarket forecasting of new products, Glen L Urban, MIT Press, 1996
  3. Placing trust at the center of your online strategy, Glen L Urban
  4. Observations on Product Management” by Dan Hill
  5. How to build a hard tech startup, Wired, 2017
  6. Product management is easier when your team can actually ship, Medium
  7. Products versus Services, Pink Elephant Blog
  8. Reboot, In search for the land of opportunity, 3rd Ed, Jawwad Farid, 2009
  9. @Rebootdude, Twitter thread
  10. @FaizanSiddiqi, Twitter thread