Product Management: when less is more [4/n] 

part 4

Make time and room for improvement!

Fact: a product has a lifecycle, which means that it will, at some point, eventually, be obsolete.

When designing a system, you should naturally check the existing technologies and use them. This way, you can:

  • focus on what makes your product unique and different
  • benefits from other people mistakes and successes
  • avoid ending up with reinventing the wheel

Keep in mind that at some point, and despite your best efforts, your choices will become obsolete. Additionally, the competition will catch up at some point. The less is more philosophy applies here as some of you features, code, etc. will be available on a new language, library, etc. Thus, you can just use them.

Remember when you wanted to create a REST API 5 years ago?  a simple XML parser and checker 10 years ago? A web server 15 years ago?

Don’t get me wrong, at some point you have to make decisions, finish your development and ship your product (unfortunately sometime it’s a JFS) but when spend time improving your system or process, you end up gaining time actually. A real-life example based on a real facts:

  1.  A feature development takes 5 days
  2.  A reviewer spend 1 day checking that it does not affect the rest of the system, and 1/2 reformatting the code.
  3.  A tester spends 1/2 for non-regression
  4. The build system takes up to 1 day

3 days, after that the feature is done, the build system fails because of a library version incompatibility. So, you go back to 1 to check it and then start over.

Now, imagine that you have 10 features to develop.

You can guess that 2 and 3 will be repeated for each feature. I let you do the math for how long will it take.

Now, imagine that you can have static analyzer for code coverage, tools for code formatting, automatic testing framework .. A lot of them are actually free, but putting them together will take you 10 days. Someone might say: HELL NO!

Again, I let you do the math.

Now, just imagine that you have all that in place, how many more features could you have done?

Short answer: while spending time on improvement, you actually ended up making room for about 20% more features.



So it’s only logical to always keep room, and most of all, time, for improvements.

Keep in mind, if it’s not working, don’t keep pushing, don’t give up, Dare to change!

To be continued


Product Management: When less is more [3/n]

Part 3

Keep it simple!

I was reading one of my old school papers about the PDCA principle on quality management, and thought that it’s worth mentioning how it can be generalized on almost every step of the Product Lifecycle Management.

PDCA, also known as Deming’s cycle, stands for Plan-Do-Check-Act. Although, it sounds obvious, you can’t imagine how many people miss these essential steps!

There is also a variant that I like a lot, which is the OPDCA. In this case, the O stands for Observe. Let’s break it down through examples:

Observe: study your environment, your competition, your existing resources (human capital,  your current resources, your potential ones, etc.) Be smart and time-efficient during this step.

Plan: define WHAT do you want to do and WHEN you want it to be done.

Do: I guess (and hope) that I don’t need to explain this one. Just remember to keep it simple by using approaches/tools that will allow you to recover easily/efficiently when you make mistakes (and yes, you will!)

Check: have tools/metrics for testing and validating what you’re doing.

Act: if your check results are not good enough, reiterate. The key phrase: do your checking results match WHAT you want, and if not when will it be the case?

And then you can reiterate. Hence the cycle.

This iterative approach, although it goes back to the 50’s, is the closest thing to current day Agile methods. Both approaches can coexist perfectly.

A fun fact worth mentioning by A. Morrison et al. : “One VP of engineering, obviously oblivious to Deming’s Plan-Do-Check-Act cycle or, as it is known, PDCA, thought the letters stood for Please Don’t Change Anything”.  Please, DO NOT DO THAT!

So keep in mind:

  • Analyzing the environment and the requirements is essential
  • Making mistakes is perfectly normal and natural. Repeating them is … well, you know … To quote one of the most brilliant minds of humanity: Insanity is doing the same thing over and over again and expecting different results.
  • Use the bugs: you cannot prevent ALL the bugs, but you can make your system antifragile* by allowing your self to benefit from them efficiently. Think about how to give your system the ability to report errors and how they can be fixed simply instead of spending too much time bullet-proofing it.
  • Live communication is fundamental, written communication is vital!
  • To quote Einstein once more: If you can’t explain it simply, you don’t understand it well enough. Meaning: If it’s too complicated to be explained, review it and start over.
  • Have a mid-term analysis: short term is simply not smart, long term is not always practical.

To be continued.

* Antifragility is a philosophical concept introduced by N. TALEB explaining how there are systems that can benefit from randomness and error. A great book that I highly recommend!

Product Management: When less is more [2/n]


Market analysis :

should describe what is expected from the product. Usually, this happens in the following way: a the product manager supervises the marketing department and describes how to address the clients needs: the Market Requirements Document (MRD) lists these aspects.


This happens in two phases: first, the macro level where we translate the MRD into a high-level concept. This is described in a Product Requirements Document (PRD) that lists the product features and main requirements.

Accordingly, the engineering team/analysts detail the PRD into sub features describing the product specifications in a functional way: how should the product behave (not the technical how). This results in a Functional Specifications Document (FSD).

Conception focuses on the “WHAT“.


Keep it simple, keep it efficient. Products are as the rest: alive and evolving. So, before translating the functional specifications into a technical implementation, consider structuring the product first. For instance, a software product requires a global architecture before start coding, otherwise, you just keep doing the same thing over and over again. This is a simple logic. Think of your architecture as general guidelines that allow you and anyone on the team to see the big picture, the map. And when you’re lost (and trust me, you’ll be), you just go back to that.

Just starts by drawing your concept and highlight your system components and actors. From that point on, you just define how each part should interact with the rest. Don’t overdo it, keep in mind that it’s a guideline. Macro first then Micro. Go from the general to the specifics. It easier to understand this way.

It’s easier to describe this through an example. For instance, if you’re building a software that manage multiple users in a networked environment to access a common database and share stuffs on it through a custom policy managed by an administrator. Your actors will be: client user, server administrator. Your system components are a client, server, and a database.

arch - New Page

Keep in mind that when you’re architecture is simple, it allows you to evolve your product without breaking it.

From here on, you can define specifics guidelines on your components according to your constraints: choose languages, define interfaces, wireframe GUIs, etc.

Development focuses on the “HOW“.


Let me put it in one sentence: an untested system is not a working one. It’s always better to find your bug, whatever its criticality, when it’s still inside your company, rather than let it slip to your customers. As a general rule of thumb, customers are not forgiving.

To be continued in the next part.

Product Management: When less is more [1/n]



Respectfully, I think that an expert has a tendancy to adjust a problem to his/her know-how instead of adjusting to the matter in hand. That being said, it is not always the case.

In this context, I don’t consider my self an expert in anything and I try to keep it that way. I believe that by doing so, I put less constraints on my approach, and allows me to keep an open-mind and my objectiveness for a problem analysis.

In the specific case of a product development process, I’ve learned that there’s no perfect way to do things. It always depends: on your market, resources, budget, history, etc. In fact, I dare to say that there’s probably as many ways as persons in a company.

Less is more in this context means that by focusing on a simplified yet complete workflow, we spend less time thinking about the what and how and focus on doing the actual thing.

There’s so many product management tools and methodologies out there, and I’m not arguing about it or analysis their pros and cons here .. In the end, they all share the same concepts.

I’ve found that what always works is to study your environment and evolve with it. Your products are alive and evolving, your documents are alive and evolving, I hope that I don’t need to remind you that your team members are alive and evolving.

Most of all, I’ve noticed that people ofter underestimate the importance of writing down their thoughts about a product and go directly to the development. For a one-shot thingy, a proof-of-concept, this might work, but then again this is not what we’re talking about here.

Whatever your product is, whatever your management method is, as long as it’s an industrial one, it goes through the same phases (which is eventually a circle):

Market analysis, Conception, Development and Validation

cycle - New Page

Let’s see how these parts interact.

To be continued in this next part