Product Management Blog

Find your next hidden product idea

Software is in essence layer upon layer of abstraction and complexity, so your next great idea could improve a challange in any of these layers!

Over the last twenty years we have seen core computational resources become cheaper and more accessible (from domain registration to cloud computing/co-location services), as well as the introduction of mobile app stores, the majority of new tech product ideas focus on web and mobile apps for end users. These are typically CRUD style apps, offered via SaaS. For the majority of product strategists, whose primary motivation may be how can I create value in this field? The barriers to entry have been steadily dropping, but the competition has been increasing due to the sheer volume of these types of products in the market. But is this style of product development in a crowded market the only option? How do we think a little outside the box here? It’s not that the products of the last 20 years of development are no longer valuable, but rather that we have created an almost saturated market for a traditional range of end-user products. Our new opportunity, as product strategists and developers, is to unlock the potential of the hidden products that this saturation of layered components has created. So, to think beyond Web and mobile apps, we need to first consider what they are made of and where there are other clients and value propositions to think about. The following is a simple way of looking at the web apps:

Front-end (runs on your browsers/generated and passed to front-end)
—-
Back-end (model, controller, and sometimes viewer components)
—-
Database(s) (in memory and/or persistent to hold the data)

The above three components (let's refer to them as `Web App` for now) work together and provide you an app. Want to add it to the internet on your own server that you are admining? then you will have something similar to the following:

Domain name server (DNS)
—-
Web App (Direct access over the internet)
—-
Server OS (FreeBSD, Ubuntu, etc.)

For the DNS, you need to purchase an IP, domain name and set up your DNS. Most likely you will purchase your DNS, so you don't need to bother to set it yourself and for the server, either you bought it and stuck it somewhere at your home (not recommended for security reasons) or you went and bought/rented a server in a data center. Let's assume you hit the chord and have 10k concurrent users and also further we assume that your server could accept 10k concurrent users, what will the overview look like?

Content Delivery Network (CDN) for serving static files.
—-
Domain name server (DNS)
—-
Load balancer (e.g., Nginx)
—-
Web App instances
—-
Server OS (FreeBSD, Ubuntu, etc.)

The difference here is that you purchase a CDN service to serve your static files (e.g., JS,CSS, images, etc.) and bring the load balancer to the front of the server so that it redirects the HTTP calls into the local instances.

So at this point, what are the components that you bought to serve your application? CDN, DNS, IP, domain name, physical server, rent in a DC. If you go into the cloud route and use a virtual machine (still keeping it basic with 10k users) then you still pay for CDN, DNS, IP, domain name and VM. Also on the free side of things (load balancer and OS) there are various paid versions such as Nginx Pro and RedHat. So first of all, all these software that you paid for in their core are not web or mobile apps and therefore you could think of similar line of products but also there is an interesting fact about them: to build them you need more than just the last shiny web or mobile framework to create them but also all of the sudden the potential impact of an alternative product becomes gigantic. Simply because you impact millions of developers and hundreds of millions of their users. So hypothetically speaking your potential product impact becomes global overnight. By the way this is just scratching the surface and staying at the Web app dependencies, you could think about OS itself and helpers and all the services could be developed and provided (mail service, security monitoring, etc.).

So let me put it this way:

To think outside the box for SaaS you need to look inside the box!

There is even more to unpack here if you are a technologist and developer: All the foundations of the internet are written outside the usual JVM-, Python, .Net-based languages and frameworks. So here is the new product hypothesis:

Over the years, layers upon layers of abstractions and components were added into our software stack. If you have a good understanding of the basis of computer science, architecture and programming, you can create small improvements in the foundations to have a gigantic impact on many software products.
For example, you can’t be an OS contributor with the latest Web framework you learned, you need to first look at the legacy code that was written decades ago and see where you can contribute with languages that today might consider them low level such as C. For example, for fun of it as I was looking into testing C code, I was curious to see when assert.h was written, so I looked at its definition in a FreeBSD distribution (also available on your Mac), that is a while back:



This goes to all other modules and services in the OS, as well as the glue of the internet: networking. Your home has a router that you are connecting into, right? What are the software that you think you can create to help the users and developers? Again, you need to know the core components and layers of the networking and most likely need to write the software in C, C++ or Erlang, depending on the brand. Or maybe you become ambitious and want to create a hardware/software product that is both router and a FTP server and release it to the market, you then need to know a number of foundations on both software as well as electronics (to design the board, sent it for fabrication, testing both hardware and software, and writing software for certain chips).
On the mobile side of things if it requires a server for supporting the app (e.g., registration, authentication, keeping the score of the game you created) then all the above is necessary but also on the app itself you need to think also inside the box and see the improvements that you can make: all the sensors and camera features, could you create a product that ease the users/developers?

Summary

To summarize, my aim is not to discourage you from learning and developing products on web and mobile technologies but rather to remind you that there is a whole ecosystem supporting mobile and web apps that you need to be aware of. The layers upon layers of abstractions and components in the architecture of today’s products offer new ‘product’ and value opportunities, waiting to be tackled if you want to create a gigantic impact. Create your next product hypothesis around the value that you can bring to a vast number of other products.

Build-in profitability from the start to your product

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

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:

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.

Summary

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!

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

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.