Product Management: 5/5

And we’re back for the series finale!

To summarize, here is my 10-point manifesto:

  • Product management is all about compromise: finances, roadmap, R&D, design, technical debt, customers request … You cannot have it all, and even if you do it will not last. So, you better stay on guard
  • Tools and methodologies are two different concepts: Agile is not about just using a scrum tool or having standup meetings
  • Best team management is the horizontal one. Of course, it doesn’t always apply (keep it real). You still can use a bottom-up approach though: let the people decide how they like to work. At least, you’re sure they will give it their 100%. Keep it real though ūüėČ
  • When it’s too hard to decide, it means that you have a risk management situation. It’s always a good practice to focus on¬†the business value. So, for each feature, you need to identify it first. For instance, what I learned from the Galaxy Note 7 fiasco, is that you don’t mix the launch of a flagship product with technical/financial experimentation. Samsung had succeeded this kind of exercise with the use¬†of exynos instead of Qualcom chips but somehow forgot about the basics. Bottom line, people were expecting a kick-ass smartphone, not a kick-ass smartphone with home-made batteries.
  • Long-term planning is rarely efficient. Short-term planning is tempting but eventually lead to short-sighted decision that eventually cost more. So keep it at¬†the middle. Technology business is evolving so fast, that you don’t have the luxury to have certainty about a 5-years plan.
  • Things will always go south. So instead of trying to control everything, prepare yourself for how to manage issues and damage control.
  • Always make room for recovering your technical debt, even a small one.
  • Team efficiency depends on its members involvement.
  • Share info. Involve others department when necessary while keeping in mind the big picture. Dare to ask for help.
  • Design your product for users humans.



Offline Rendering of GitHub Mardown

Why not a dedicated App?

I’m not a big fan of having a massive amount of windowed interfaces.¬†A terminal emulator and a web browser are good enough¬†for my daily routine.

When I document one of my projects on GitHub (yes, I do that), I have to write a markdown document (the README): it is very nicely rendered, first by markdown processors, then by web browsers.

However any graphical production must be visualized before being¬†published,¬†that’s just common sense.¬†Conversion from plain text to a fancy¬†rendered document¬†never goes well at the first attempt. There are always one or two¬†line endings that get smashed because you forgot to leave an empty¬†line in your markdown, an emphasis on word missing, etc. Of course, I’m not talking about¬†syntax errors since¬†mainstream text editors, such as vim, provide¬†pleasant syntax highlighting that prevent you from¬†messing the markdown up.

Let alone the fact¬†that¬†there are like a¬†dozen of different markdown flavours…

I simply don’t want to end up pushing my documentation to GitHub every time¬†I want to visualize what I just wrote. Some might… but I guess.. that’s not¬†the way to go, if you like to keep your repo history clean.


One day, Google, my good old big brother, gave me a solution to this dilemma: grip.

Grip is maintained by Joe Esposito. It is a command-line tool written in python, available through pip and which generates a preview of a markdown document. The latter is directly available on your web browser!

cd path/to/where/you/have/a/
grip -b –quiet¬† # -b to bring in the web browser, –quiet not to echo in the terminal (it bothers me)

And boom! The markdown preview is served to you on a silver platter!
when you are done, just <CTRL-C> in the terminal to kill the local server that
grip created.
Oh, did I forget to mention it can track changes as well?

For more details, please refer to grip`s README, well, written in markdown
of course:

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