Product Management Blog

Capturing 'Aha!' moments

Build-in profitability from the start to your product

Know cost to production of every user, every single one!

Tags: #product-management, #core-concepts, #product-strategy, #product-value, #product-profit, #start-up, #start-up-strategy

For the last 13 years, the stock market has been mostly profitable when it comes to technology. Since 2010, a number of unicorns came into play such as Uber, and they have managed to float and just become profitable in recent years. Amazon became profitable only in 2014, and there is a game to play where you convince investors that in the future money will come and you play that hand until you make it or go bankrupt 🤷. However there is another way, a safer, logical way to build your product and make money along the way and keep your sanity. It is has a simple comon sense rule:

Required number of users to profitability: you should know exactly how much your software and hardware cost and how many users you need to have to cover that.

In other words you should know when you will break even on your investment:
Break even formula: Cost of all software + cost of all hardware = # of paid users.

Here the cost of software and hardware includes everything that contributed to building the software/hardware, meaning office space that engineers are operating at, software licences, the server rack or the cloud instance that is in the office for your CICD purposes, even the laptop that was bought for newcomers. Then you need to decide how many users you need to have to break even. Unless you are creating a niche healthcare product that you only sell to hospitals that have brain surgeries for hundreds of thousands of dollars, you need to have 100s or 1000s of users to break even, and here the decision is yours! The bottom line here is that you need to know these numbers by heart at all times.

Individual Cost. Based on your decision on when to break even, you should know exactly how much it should cost for each user. To keep it simple, if the product costs you 50k per year, and you want to break even with 500 users, you should charge 8.3$ per month if you want to go subscription based or 100$ per annum. Again here there is another decision you need to make regarding having a flat fee or subscription or giving a discount if someone wants to pay annually.

It is best to use this formula right from the start and take into consideration everything you do, because your customer pays for it! For example, it is not wise to set a Kubernetes cluster when you only have a small number of containers right from the start (do you even need containerization when you can run your back-end of a Unix box somewhere?. Or start using cloud ‘buckets’ or databases for storing data when you can use the same Unix box and save the data into the Postgres database. Needless to say, you need to take security seriously, here the simplification of the techstack is to save money.

Development teams and these numbers. This brings me to the next point that everyone from the team should know these numbers, regardless of their job title or position. And for every task/user story that the team is doing, they should know that they contribute directly to the users, either by saving money for the company (reduction of cost for the user) or value for the customer (justification for the cost of the product).
Healthy Margin. What is the healthy margin? If you want to bring it to the next level, you should think of your product margins. A good healthy product has at least a 40% margin, meaning if it cost 100$ you could sell it for 140%. If you keep the margin healthy from the start and make your decision based on the above formulas you are good to go.


In summary, don’t forget the following numbers:

  1. Cost of making: the total amount that is required for your company to spend to create a product (both hardware and software).
  2. When you break even : after how many monthly/yearly paid users your product becomes profitable. Health margin: what is the health margin of your product?

Learning to say no

How to identify over-hyped product ideas that need to be shut down... immediately!

Tags: #product-management, #core-concepts, #new-technologies, #product-development, #product-lifecycle

As far back as I can remember, every couple of years one technology, product, or idea captures the imagination of the masses (think of ‘plug and play’ hardware), like a new star in the sky. Suddenly, everyone from every corner of the Earth, points towards this magnificent source of light, as if it will provide the solution to their eternal youth. At this point in time there is a stark difference between the ‘creator’, the ‘consumers’ and the ‘makers’. We may congratulate the creators for their vision, even if it is just at marketing level (not an easy thing to do), but what does this mean for ‘makers’, those of us who have to make this idea a reality?

Now that we have ChatGPT and soon `Apple Glass`, I think it is a good time to address this difference between creators and makers and answer the question of “what to do when we need to plan our next product”. So, in this post I will group the reactions that product creators do into four groups and how they react to these sorts of events. Also, I try to be inspired by nature and use the creatures in the ocean for these four groups!

The first group of people go all-in on the idea but take a parasitic approach, juggling the uncertainty of the ride on an unpredictable host with the excitement of the opportunity to exploit it. Let's think of them as cymothoid isopods! The parasitic creature that acts ‘as a tongue!’. These people see an opportunity and try to benefit from the media interest. In recent years, the example of it would be plugins, third-party services for Bitcoin, NFTs, and most recently ChatGPT. Services, websites, plugins and “gurus” jump out of nowhere and try to ride the hype/marketing train and try to use today's market “winner” as the basis for their add-on products. In the physical world I could think of the proliferation of cheap and not-so-cheap phone cases (for the record I hate them all!). I can just imagine the poor bastards, sitting around for the phone schema to create the new cases for new phones and pollute the Earth one more time. There are three main issues here:

  1. “I'm your father”: these people are consumers themselves, and if the last year “winner” (NFT) passes the torch to the new “winner” (ChatGPT), they are done, period. All their efforts went to nothing. Want to write an app for a BlackBerry?! yOu sIcKo, please don't! 😀
  2. Competitive nature: it becomes very competitive to operate in such an arena, as everyone points their vehicles GPS at the target but forgets about the traffic. Yes there will be a winner or two but get ready for a very serious close-to-the-bone competition. There are people waiting for a particular wave to come in, and they jump on it right away as well, so it is almost impossible to make something meaningful as soon as the news hits the mainstream media.
  3. Short-lived Hype: to build on the second point, even if you want to do the work and learn the core of this new hyped technology, you should be pretty… pretty… fast, unless you want to be a scammer (I hope not!). There are people that got their PhD on AI in the 1980s and continued to work on it in Big 4 companies, so now the current hype AI train came about, they are most likely to have their armour ready.

So the moral of the first point is don’t be a scammer that works on hyped tech news, don’t be a cymothoid isopod!

The Second group of people package well and add a core business for the consumer such that the consumer really doesn't need to understand the underlying technology but is very happy with the idea of a product with new shiny features that provides real value and is happy to pay for it for a long period of time. If you look in nature you can think about a nice shiny shell that the octopus is using to hide. You can think of Spotify, Netflix, Amazon’s AWS, or the recommendation engine that Amazon uses on its products pages as such products. No problem with the business model, but the challenge for ‘makers’ is how to get there.

  1. Use as a helper not the selling point: let's take Cloud technologies. What is it really? A set of servers in different locations providing seamless support. The seamlessness is the part that consumers care about, so when AWS builds its products in this space, it doesn't bother the consumer about which Data centre is being used for the servers, and what software is using for switching between its internal network. It uses the technology as a helper and builds something valuable on top of it. The name they use also represents that: Amazon Web Services, and there is no mention of “cloud technologies” in sight.
  2. Selling point, the value: selling point is always the added value and always will be, so if you want to integrate well, think about what true value you add.

Third group of people are just pure scammers. They don't even try to hide the packaging, they just start exploiting the unwary for quick gain and have no valuable offering behind it. In the history of technology you can look into the dotcom bubble (where useless websites were valued in millions by abusing Internet boom) or crypto exchange loses (by abusing Crypto currency hype). Think of them as the vast plastic garbage gyres in the oceans, the accumulation of many small problems that have existed for years unfortunately but reached a point where there is so much that it can’t be ignored. Again, don’t be a scammer, don’t be ocean garbage!

The fourth group of people focus on core issues year in and year out. They really don’t care about the hype, they have their technologies set and try to build on years and years of research and work. For example, people are developing and updating the Unix Kernel or packaging and building systems for Linux (whatever the flavour would be), they rarely change their technologies and keep roaming in their own dark space, building… and building. Like Angler fish at the bottom of the ocean, roaming and cruising and knowing where he/she belongs and does what he/she does best. Their work is pretty much at the core level of technology, but if they create a new product in this space it is monumental because every other group of people are building on top of their work. Imagine, a person comes with a better module for Wifi connectivity for Linux machines, every single Linux machine on earth would and should use it. The downside here is that even core technologies change, and because these groups of people require years to build and add something to the core, they have a risk of failure, but that is pretty slim. For example, the pocket computers of the 90s had Infrared connectivity for data transferring. Those were troublesome and moved aside when bluetooth and Wifi became more prevalent. It didn't totally die (still used today in face recognition technologies) but you could imagine if someone wanted to build a product on top of that for better data transferring technology, they are out of luck.

To summerise, these are the points that you need to be aware of and say no to, when it comes to create new product using new technologies:

  1. Say no to parasitic type products.
  2. Say no to the products that don't use new technologies as a helper.
  3. Say no to the products that don’t add any value to the users.

Six Traps to Avoid as a New Product Manager

Read this before accepting your first product management job

Tags: #product-management, #first-job, #product-development, #product-lifecycle

Having a product management role is a luxury that many companies cannot afford and do not invest in. Therefore, for anyone who is fortunate enough to be a product manager or wants to become one, it is important to learn their craft well, identify opportunities and pitfalls, and provide the most value to the company. In this post, I share my advice on how to navigate your way in this role, and highlight the most important traps to avoid.

First, don’t forget your position as the champion of a great product in the company. I have seen PMs take the Manager part seriously but avoid the Product! It is vital to orient your management focus to match the lifecycle of the product. Build relationships between all the team members to fully focus on development, delivery and support of the product, but avoid becoming solely a people-manager. This requires honesty and transparency right from the start. If the business case is not clear, don’t just push the product to your technical team, take the discussion (even if heated) to the budget holders on why this product should be built at all. If you are in a more senior product management position, the reason ‘why’ to build a product becomes your duty to justify, so don’t forget that your success will be judged on the success of the product, not on how many people you are managing.

Second, as a product manager don’t forget that product development is an iterative process, so don’t look for big-bang success anytime soon. You are invited among the big guys and gals to talk about the next big thing, your heart is pumping and you might find yourself in a corner nodding in agreement to whatever they ask, and you promise the world. This is when you need to remember you can’t get to checkmate in one move, you need a plan that is based on iterative growth, this way you can manage expectations better and give yourself the buffer to improve your plans along the way.

Third, you are in this luxury role, required to remember that, you sometimes need to hold your ground and say no when product aim doesn’t make sense. Once in a while people might ask you some stupid nonsense to build and attach ‘business growth’ or ‘what is hot at the moment’ to it. This is when you need to say “this does not make sense” after you did your background work, for example look at the following image, I asked the user of the system if she uses the camera on the device or even if she uses that. She said: ‘I have no idea and never used this to get the payments.

Fourth, before you jump into presentation mode, and put your wizard hat on why this product will rule the market, know the technical points before making the decision. I saw so many times PMs jump right into a presentation, spreadsheet and if I ask them: “ok who will pay to get the authorization key for the API we are going to use and how it will affect the current authentication mechanism?” they will have no idea. So they spent all this time to use an API and advance the current user experience, but have no idea how to combine it with the current flow, so know your tech Sir/Madam!.

Fifth, a product to work in many disciplines needs to work together, be a PM of such teams or demands to be in one. This is the continuous of the rule #1, if you stay in a one discipline team (e.g., back-end, DevOp, etc.) you will end up being a people manager, because people already know what to do, and you will not be able to impact the overall product, so avoid such teams.

Sixth, your roadmaps should always be one click away regardless who you talked to, this way you can always stick to the plan or discuss the plan in detail if necessary. People have many things on their minds and once in a while you need to remind them where the team is, so always be able to present your roadmap and be able to update as soon as something changes. Everything starts there and finishes there when you talk about the team that is working on your product.

To summarise, don't forget the following six points and avoid them at all costs:

  1. Don't be a people manager.
  2. Don’t look for big bangs.
  3. Don’t say ‘yes’ to everything.
  4. Don’t be a presentation wizard.
  5. Don’t be a PM on a single discipline team.
  6. Don’t avoid your roadmaps.