DEV Community: H-J Johnson

Velcro – What can Product Managers learn?

H-J Johnson — Fri, 28 Aug 2026 17:49:24 +0000

Why do some products fail and others succeed?

How do we create genuine value by solving real problems?

These are questions that fascinate (and fuel) me as someone that builds. Every week I take a look at successes and failures in history across industries with the purpose of extracting lessons for Product Managers (and everyone else) to learn and draw inspiration from.

Today we look at Velcro. We focus on the idea and resulting product and not morality, human rights, etc. The Product!

When laces, buttons, hooks, buckles and pins are predominant, why would anyone want to create a new way to fasten garments? Velcro was invented to do the same thing that others have been doing long before it arrived. A new way, for that era, of doing the same thing. This article is focused on the Product and what we can learn from it.

Take walks/other activity: It is important to clear your head and there are many ways to do it. Taking a walk, sitting down quietly, napping or any other way. Whichever you choose it is important for you to refresh and recuperate! It is in this moment that new ideas and fresh perspectives come to mind. When you are constantly doing the work and buried in the activities of that work, chances are you are not seeing anything else outside of the job. Every now and then lift your head up, away from the chaos of the tasks at hand, and see what is around you. George de Mestral, the Swiss Electrical Electronics Engineer, was on a walk (some literatures say hunting trip) when the opportunity for inspiration occurred. The lesson here is to find the time to take a walk or do something else that helps clear your head. I do not know how many walks it took for him (George de Mestral) to encounter this inspiration but learn the lesson.
Pay attention/Observe: We move about our daily lives without much care and attention. Certain things happen that we simply miss. Busy schedules, short attention spans, pressure from life as a whole and (these days) our mobile/smart devices have us hooked. You need to pay attention and properly observe in order to identify/extract a problem from any situation. You do not pay attention if you cannot even see! How will you see if you are not present in the moment? “Your eyes see what your mind wants it to see”. Being present in the moment is the first thing. Seeing is what comes afterwards. Paying attention (to what you are seeing) comes third. Observe properly what you are paying attention to; that’s the next step. As the story goes while on a walk (remember opportunity to clear one’s head and allow for inspiration), George de Mestral noticed burdock burrs sticking to his clothes and his dog's fur. This was what inspired him! Burrs, in Botany, are prickly seed pod or fruit casing covered in tiny hooks that catches on clothing or animal fur. Burdock is a large, wild plant with big leaves that usually has sticky, prickly burrs that easily cling to clothing and animal fur. If you are in an opportunity and cannot even pay attention and observe, then what’s the point? The lesson here for Product Managers is to build their ability to be present in moments outside of work so they can see and eventually pay attention and observe.
Commitment: When you observe something, it takes a lot of commitment to follow through and bring anything of value into reality. George did not just shrug off his observation, he went to work on it! According to the story, George looked at the burrs (from the wild plant burdock) under a microscope and saw hundreds of tiny hooks catching on loops of fabric and fur. George committed to testing several materials to recreate the hooks from the burdock burrs he had observed under a microscope. After years of testing he discovered that heat-treated nylon formed strong, durable hooks. That out of the way, he then created the special loom to cut nylon loops at an angle to form the tiny hooks. The level of commitment here is what I want Product Managers to learn from this story.
Invention/Innovation: While there is a difference between invention and innovation, I will not discuss it here. We need to be inventive Product Managers in order to create something new. The inventor Product Manager is a rarity! To be inventive and innovative Product Managers need to build the ability to exercise their observation abilities. The lesson here is for Product Managers to be an inventor and innovator.
Build it and they’ll come: I will be blunt, this doctrine is old and might not work as it did during the time it was so popular. Usually, I encourage people to start with a real/actual/existing problem! But in order to apply this doctrine in recent times one must be extremely careful!! Think about it for a moment what actual problems existed to motivate George de Mestral to commit to bringing his idea to life? There were other clothing fasteners at THAT TIME. George’s commitment, I would say, was simply the nature of inventors at the time. Something sparked his curiosity and triggered scientific inspiration and he simply ‘gave it a go’. For Product Managers to apply this today they must quickly establish a POC (Proof of Concept). A POC (Proof of Concept) is not a Minimum Viable Product (MVP) but it can suffice to send the message across about what the idea is. POCs can be used to get feedback from a target customer section and modify any ideas.
Another way is to FIRST establish a real/actual problem that might not be immediately obvious to a larger number of people, yet. Have that problem as the basis to move towards an MVP. Present the MVP to the market and collect as much feedback as possible. The difference between the POC and the MVP is that the MVP is a simple version of the Product that is built into reality and can be more practical than theory. The POC is more simulation/description/presentation of the idea and can be more theory than practical, depending on the situation. The lesson here is to know which to use in order to apply this in today’s era. Again be very cautious as it is dated doctrine!!
Perseverance: How do we know when to kill an idea? Really what is the time frame to ensure we are not in the territory of ‘sunk-cost fallacy’? Do we kill or pivot an idea? The lesson here is to be mindful on what we preserver on! The level of perseverance that George showed is just significant of the era/time period. There was no guarantee that he would have succeeded! If you have found a genuine problem that has triggered your inner urge to invent and innovate then keep pushing. That’s the lesson for Product Managers here.
Actual problem: Velcro is a way to fasten garments! That is an actual problem!! While there were other methods of fastening garments in that time period it was still a problem. The lesson here is to focus on real/actual/existing problems. Now, do not just identify a problem, you have to understand the problem and spend time in the problem space.

As I have mentioned there is a rarity in the Product Manager space. I refer to this rarity as ‘Inventor Product Managers’. It is possible for Product Managers to be inventors and innovators. That’s the essence of this article and my entire newsletter as a whole: https://lnkd.in/eZVmuq-7 .

Join me every week as I look into histories from diverse industries and extract lessons for Product Managers.

🖼️: Copyright owner

H-J Johnson

My Book: https://lnkd.in/d-8ZAxEa

My Newsletter: https://lnkd.in/eZVmuq-7

Medium: https://lnkd.in/dDqCAq27

Substack: https://lnkd.in/d47SKJEQ

Dev: https://dev.to/h-j

LinkedIn: https://lnkd.in/dgMSkB5h

https://lnkd.in/eaQwiacU | https://lnkd.in/d-8ZAxEa

agile #productmanagement #ai

Bic — What can Product Managers Learn?

H-J Johnson — Mon, 24 Aug 2026 15:48:01 +0000

I love BICHES! Really do!!

Seriously though.

Imagine if Marcel Bich had insisted on keeping the name BICH rather than shortening it to BIC, as advised. There are lessons that Product Managers can learn from the successful history behind the BIC Crystal Ballpoint Pen. This article is focused on the product and not morality, human rights, etc. The Product!

One person observes a situation and brings an idea to reality. Another person looks at it and improves upon the idea pushing it further. Today, the Bic Crystal ballpoint pen is everywhere. In that successful history there are several lessons that I am sure will be useful to Product Managers.

Actual problem: László Bíró solved an actual/existing problem. The story is that fountain pens had a smudge when used to write and the ink took longer to dry. The lesson here is to identify a problem and start with THAT problem. Do not go churning out stuff that solves nothing for anyone. It is easier to solve a problem than to have a solution trying to fit a problem. Marcel Bich made the solution, that was created (by Bíró), even more efficient. Another lesson here. When you start solving a problem look for ways to make the solution more efficient. It is ok to have an initial solution that is not perfect but at least it solves (and is focused on) a problem. Later you can look for ways to make your solution efficient.
Pay attention/Observe: To identify / extract the problem in any situation, you need to pay attention and properly observe. You do not pay attention if you cannot even see! How will you see if you are not present in the moment? “Your eyes see what your mind wants it to see”. Being present in the moment is the first thing. Seeing is what comes afterwards. Paying attention (to what you are seeing) comes third. Observe properly what you are paying attention to; that’s the next step. According to the story László Bíró worked as a journalist and noticed that printing ink dried quickly, that was his first observation. The second observation was some children playing with marbles in a puddle. If he (László Bíró) had not been present in the moment to see his surroundings, he would not have paid attention to the children playing with marbles and made an observation that led to the ballpoint pen. He also would have not observed the properties of printing ink that he used in his invention. The lesson here is twofold: expose yourself to enough experiences that can trigger that creativity (and questions) inside you. Be ready and equipped to identify / extract when there is something (genuinely) in need of improvement.
Invention/Innovation: You need to be an inventor and innovator, as a Product Manager. I will not go into details on the difference between invention and innovation. But to succeed we need to be as inventive and innovative as László Bíró and Marcel Bich. Inventor PMs are kind of hard to come across. To do that, you need to know how to apply your observation/attention skills to bring into reality a solution. That’s the lesson here.
Build it and they’ll come: This is old doctrine that can be risky to apply in today’s circumstances. This worked when it did (it worked for Bíró’s ballpoint invention and Bich’s improvement when he got the patent from Bíró), but it has not worked so much in recent times. However, it can still be applied (with extreme caution) to achieve good results. For this to work you need to FIRST identify an ACTUAL/EXISTING PROBLEM. If you are sure, it is a problem, you then need to make sure that it is a problem worth solving!! These two things are VERY IMPORTANT to apply this olden days’ doctrine. From here, aim to achieve a Minimum Viable Product (MVP) as quickly as possible and then push to promote it! As long as it is a problem identified and worth solving you can push a well-planned MVP. You might not have a well-thought-out strategy, and all that stuff but you have an MVP built from an actual/existing problem. This is a way that I feel the ‘ancient’ doctrine can be applied by Product Managers today. That’s the lesson.
What you know: You do not know everything! László Bíró’s invention was not perfect, it was not efficient, but it proved the idea in reality. In hindsight, I feel he (László Bíró) should have found a way and committed to improving his creation or even partnered with Marcel Bich on the efficiency improvements. That aside. You may have come up with an idea (and brought it to reality) but someone else has ideas on how to improve it and make it efficient. That's one lesson. Now after the patent acquisition, and the improvements, Marcel Bich did what any self-respecting inventor of the time did. He called his new product Bich, after himself. To him, it made sense and was logical. But he hired someone that advised against it and gave reasons. Second lesson here, you can always adjust the name of your product. You do not have to use the first name that comes to your mind. Third lesson, pay attention to trends in the market.
Entrepreneurship: Thinking different takes a lot of guts and conviction! When everyone wants to do things a certain way, it takes a genuine entrepreneur to see (and do) things differently!! Entrepreneurship goes beyond registering a company and opening up a place of business. At the very foundations it is about inventing and innovating solutions to real/existing/actual problems. At the time Marcel Bich got the patent from László Bíró for the ballpoint pen, fountain pens were all the rage and fully established in the market. Think, why didn’t László Bíró join the fountain pen crowd? Why didn’t Marcel Bich go focus on a fountain pen factory? The answer is entrepreneurship! The lesson here is for Product Managers to be entrepreneurs and confidently think differently. It is easier said than done. Trust me I know. The lesson here is to think differently and be a GENUINE entrepreneur.

I can go on and on about all the lessons that Product Managers (PM) can extract from this historical event but the above six (6), I am sure, are suitable enough to trigger something in a determined Product Manager.

Are there other lessons that you can point out from the history of the ubiquitous Bic Crystal ballpoint pen? Let’s discuss it.

🖼️ : Greg Rosenke on Unsplash

H-J Johnson

https://lnkd.in/eaQwiacU (Free) | https://lnkd.in/d-8ZAxEa (Paid)

Medium: https://lnkd.in/dDqCAq27

Substack: https://lnkd.in/d47SKJEQ

Dev: https://dev.to/h-j

LinkedIn: https://lnkd.in/dgMSkB5h

Startup (Product) Mistakes

H-J Johnson — Mon, 17 Aug 2026 05:51:26 +0000

There are some mistakes that I see startups make across different industries regardless of the type of product they are working on. Now, these mistakes happen for many different reasons. It is important to discuss both the mistakes and the reasons why such mistakes happen. This way, we not only bring the issues to light but also the root cause of said issues. A few mistakes I have noticed:

NO PROBLEM: One of the mistakes that I have seen is people jumping into building/creating without an actual/existing problem in sight. Ideally, you first identify a problem, validate the problem, understand the problem, talk to potential users, etc. Meaning you confirm if it is even a problem in the first place. If yes, you check if said problem is worth solving at all! It is easier to solve a problem that exists, than create a solution that is looking for a problem. Most people just jump and build, that is wrong!
Features machine: Releasing features just for the purpose of having more features rather than trying to identify where REAL VALUE is and what it looks like for the customer/consumer/user. This is a mistake that seems to have increased with the recent AI hype. Now features can ‘roll out quickly’ but no one is asking if it ADDS VALUE to the people in the target market. Really, does it solve the problem of the user/customer? Will the user/customers find the need to USE THE FEATURE? No one is asking the critical questions anymore, it seems. And this is bad.
Beyond execution: From the beginning, achieving success is beyond execution! Another mistake startups (and the people within them) make is that they are stuck in execution because they think it ends there. NO, it does not! After execution there is operations, distribution, delivery, support, success, etc. Now, many startups make the mistake of skipping all these other areas and just focus on execution. Do not get me wrong, execution is great but without including all these other areas that I have mentioned there is going to be bottlenecks from the start. My argument, include all the critical areas at the drawing board, have them in place (to some degree) from the start

How do these mistakes happen? A few reasons:

Hubris: At every section of the organisation. From experience it is not just top-level management that displays hubris it can also crop up at lower levels as well. When individuals cannot separate reality from their delusion, that’s a problem. I insist that CONFIDENCE is not COMPETENCE, so COMPETENCE must be CONFIDENT. I am for confident actions but it has to be backed by ACTUAL COMPETENCE and NOT delusion and complex.
Culture: At this point it is not the Product team alone but the entire organisation. There are organisations where critical thinking is a crime, experimenting new avenues is a curse, having misplaced priority is normal, it is culture not to balance product with sales and all else. In this situation there is a nothing a ‘world-class’ Product team can do.
FOMO: 'Fear is a powerful thing'. I argue, wisdom is stronger! Even in a rush, if you are calm, you can achieve even greater success than others without joining those in the rush. Read that again and let it sink in.

There is nothing wrong with making mistakes but there is a serious problem when you do not learn from those mistakes. The learning bit makes the difference and it is what separates stupid people from brilliant achievers.

Image credit: Quilia on Unsplash

📖 Learn: https://lnkd.in/eaQwiacU (free) | https://althjj.gumroad.com/l/ntmrs ($7)

🖊 #hjisthinking (H-J is thinking 🤔)

🤼 Follow H-J Johnson and hit 🔔

🔎 LinkedIn | Medium | Substack | DEV

Nintendo Hotline – What can Product Managers learn?

H-J Johnson — Sun, 16 Aug 2026 23:38:44 +0000

Nintendo had a hotline where gamers could, at the time, call and speak with 'Game Counsellors' who provided them with tips and walkthroughs. It operated for quite sometime before Nintendo sunset it.

There are a few (Product) lessons from this that I am sure will be of value to Product Leaders.

1- Necessity (Invention's mother): The necessity of a situation usually births the creation of something that stands out from the rest. While Nintendo was not the first to use a phone as a 'business' function, it proved it can be used in the context of a video gaming community. That was their ‘necessity’. "We need a way to accomplish ‘xyz’ " usually turns to creating something specific to that situation. The ‘xyz’ in Nintendo’s case was supporting gamers instantly. It could also be something to support a Product or make it easier for the customer. It could be a feature or it could even be the Product itself. All we need to do is pay attention to our necessities, needs and allow it to guide us. Most people are not paying attention to their needs that’s why innovation and improvements appear difficult. Others know what their necessities are but prioritise wrongly – well that’s story for another day. The point here is simply to build for a necessary problem that exists and not out of assumptions.

2- Know what is available immediately: If necessity is calling, we cannot keep it waiting. We need to look around to know what’s available immediately. In most cases we do not need to go far for solution, we just need to pick what is close by then structure it to align with current needs. Sometimes the necessity demands using/importing an idea from some other place into your own specific area. In retrospect, Nintendo had other options it could have considered at that era in time. During that period, it was common to use print media to relate with the computer (and also gaming) community. There was also postal mail, bulleting boards. I do not know for sure but I am guessing the team at Nintendo could see the drawbacks in choosing the alternatives at the time. The most simple, direct and available option was picking up a phone and having a conversation. To create something, it is usually best to start with what is obviously available in front of you. Consider your options and weigh them all against your situation. Continue from there.

3- Customer support and Customer success: This is integral to your operations! It should not be treated as an after thought but as a critical business function. NOW do you remember the necessity I talked about earlier? This was the ‘necessity’ for Nintendo. Their ‘xyz’, as I put it earlier. How do we help our gamers resolve difficult situations they encounter while playing our games? How can we encourage more people to play our games and in so doing get feedback from actual users. I do not know for sure but I reckon these are questions that came up at Nintendo. Here we can learn that putting in place a system that functions to assist existing customers is critical. Don’t leave your customer stranded. Don’t leave them hanging. While using your Product they might encounter situations where they need your assistance. Be ready to guide them through.

4- Operations is crucial: Someone always had to be at Nintendo’s end to answer the call – and there were many calls, I presume. I am sure it was not just one operator supporting the hundreds of gamers who were calling in. This is where daily operations comes in. In order to ensure that this solution to a necessity ran smoothly there had to be some sort of operations guidelines. This operations aspect is something I also feel can be a key takeaway for Product Managers. While everyone just sees the Hotline, I see and understand the operations detail needed to keep it running.

5- Marketing to boost sales: Nintendo brought in a TV Station to record what they were doing and how they did it. Sometimes it is a good idea to show the customers what you do behind the scenes to make them happy. Communicating, with evidence, that you put in the effort to support them goes a long way. Inviting a TV crew to come and witness first-hand how the Hotline works was a good marketing move that I am sure boosted the number of gamers that wanted to make use of the service – and also the confidence of the ones already using it. A gamer seeing a gamer helping other gamers get unstuck – how cool is that!

In summary, Product Managers should see from this late 80s Hotline solution from Nintendo that Product Management is not just about building products. It is about solving problems and ensuring that there is a suitable environment for the solution to thrive! It does not end with Problem Solving. The solution has to be surrounded by several other key areas like operations, marketing, support, proper prioritisation etc.

Nintendo paid attention, prioritised it necessities properly, then weighed obvious options and used what was available. This is something worth learning and applying in our Product building and overall Product Management endeavours.

H-J Johnson

https://lnkd.in/eaQwiacU (free) | althjj.gumroad.com/l/ntmrs ($7)

Substack | Medium | LinkedIn | Dev

Can it scale? (First Part)

H-J Johnson — Sun, 16 Aug 2026 17:46:17 +0000

I will do my best to clarify what the term ‘scale’ (actually) means.

TLDR

Technology Scaling is not Business Scaling although they can work together for success
Servers / Infrastructure is a tiny fraction of the overall scaling discussion
Servers / Infrastructure falls under Technology Scaling
All the servers in the world does not mean you are scaling
Core Code + Delivery is the ordered combination that should be followed to achieve technology scaling
There is a side of the scaling conversation that involves physical locations!
Business Scaling is another ball game that I might address much later

Let dig in!

The questions ‘Will it scale?’ and ‘Is it scalable?’ are very common in the software product / technology domain.

A lot of people just think of only servers and infrastructure. There are groups of people that only think physical locations and nothing else. Most people are just outrightly clueless and do not even know what they mean when they talk about scaling/scalability!

Allow me to guide you beyond buzz words and theories (ahem ‘blitzscaling’). When addressing the question of scale think of two main categories, namely:

a) Technology

b) Business

Technology scaling is not business scaling and vice versa. However, if done correctly both can work hand in hand for greater success. I will tackle technology scaling first then later in subsequent parts, I might break down business scaling.

Let me start this technology scaling lecture with laying a foundation by saying this, if you have all the servers in world, all the cloud instances in the world and the core of your software product is in shambles you cannot scale! In such situations, when asked if you can scale you should not answer yes, at all.

For any software product to scale technologically, you require two things: 1) Core Code 2) Delivery. These two (2) areas are what you should consider when talking about technology scaling.

To understand this, consider two sides of the spectrum: Side One, making software for others to use. Side Two, relying on software to thrive. Stay with me I don’t want you to get lost. This is building on the foundation laid above. I will start with Side One to explain technology scaling.

Side One (Making software for others to use):

Consider a company that provides a solution to other companies. Company A has Client A as a customer. Client A is a good customer and wants to recommend Company A to members of their association. So, twenty new customers approach Company A but their Core Code is not as it seems. To carter to the twenty (20) new customers, Company A has to fork the code base each time. So now they have twenty (20) different codebases, one for each of the twenty new customers. Company A realises they are in soup and cannot take on new customers. They cannot scale because their Core Code cannot scale. Their Core Code is not scalable so they aren’t scalable! Any new customers that come along means newer forks so they simply turn them down. Do you see where this is going? Not yet? Keep reading. Now for each customer that Client A helped bring in they have servers doing server things (cloud, serverless, whatever). All the compute, storage, database and networking Company A deployed for each customer makes it seem that their solution scales, but that is false!!

Side Two (Relying on software to thrive):

Consider a company that needs a solution to aid them accomplish amazing things in their industry quickly and without hassle. Company B meets Vendor B to adopt a solution and move on with their activities. Along the line they (Company B) realise every simple tweak needs the software vendor. They cannot create extensions, plugins, other things that will give them some sense of freedom as users of the software. As if that is not emotionally draining enough this company’s users keeps growing but the Core Code from Vendor B is not allowing Company B to soar as their user base grows. Apparently, the vendors of the software (Vendor B) did not design it for massive use but rather for a company with no intention to grow to millions (and even billions). Ouch!

With the spectrum laid out atop the laid foundation (I think) you should better understand technology scaling. There is an order of things to achieve tech scale. And that order is Core Code first then Delivery second (it’s ok to disagree with me but my experience has shaped this opinion). Most people make the mistake of discussing parts of Delivery and think they are addressing the scaling question but that is a huge mistake! I will do my best to describe Core Code and Delivery below:

1) Core Code: this is the code at its core! How it is designed, written, structured and organised. This is where the scaling analysis begins (or in my opinion, must begin!). If this box is not ticked (and ticked well for that matter), forget any servers or cloud infra you have in place. If you are a software vendor/author, take out considerable time to address this part of the scaling discussion. If you are an organisation shopping for software, ask questions about this area. So, what makes a great/solid Core Code? Over the years I have created a detailed checklist of areas that needs to be addressed but I’ll list a few pointers here. These pointers take the form of questions and statements that will serve as a guide. I will also try to use examples existing in the market.

Statements: Never confuse setting up and signing up as the same thing, they aren’t. A solid Core Code is not custom built for just one person but rather for the general market with the liberty to modify per their needs. A system with a solid Core Code has to be API first and the APIs have to be error first APIs. Being modular really helps in keeping a clean codebase at the core. A solid Core Code will evolve into a community that includes not just users but service providers and developers as well. A great Core Code is delivered by a solid and well thought out development pipeline. It is not every type of software that will need to provide a system for the masses to create plugins but internally it is a useful way to move quickly and efficiently.

Questions: What is the setup process of the software and how easy is it to complete? How easy is it to signup? How are accounts managed after signup? (Individual accounts, company/organisational accounts, accounts hierarchies and possible transfers, accounts cancellations/deletions, accounts updates/modifications). What are the defaults for every action along the way? How will pricing be enforced/implemented? These are just a few questions.

To further understand ‘Core Code’ in the way that I see (and understand) it, I will use one of my favourite opensource projects, Drupal (I will not discuss Acquia here). Every user gets a foundation copy of the software and sets it up in their own environment. It is not a custom software for only one person/organisation. Typical of any solid Core Code is the foundation copy given to users. This copy is usually a plugin architecture that enables the users to build their own modifications (modules, themes, distributions) or obtain one from any trusted marketplace. This freedom offered by the software allows users to address any needs that may arise. It does not lock down the vendors to just one user but allows multiple users to get the software. It also does not cage the users as they can modify the software by adding new capabilities. Achieving solid Core Code for SAAS vendors is somewhat different since they want customers to use the software on their domain (ie the vendor domain). But the idea is relatively still the same. Give the user a foundation copy and the option of adding modifications (created by them or obtained from a trusted source). Think Shopify and how we now have Shopify developers and a thriving community. There are other SAAS vendors in other areas asides ecommerce that give their users such freedom.

In the most basic form this is what it means to be able to scale at the Core Code level of the software! A foundation copy, the user can then extend/modify per their needs/use cases!!

2) Delivery: the means by which you get the software product into the hands of the user. If this box is ticked and the Core Code is not ironed out properly then (in my opinion) you have a problem! Delivery is basically how your product gets to the hands of customers in the market. Delivery is easy when your Core Code is in order from all perspectives (design, processes, architecture, etc).

Back in the day CD-ROM was the way many vendors got their software in the market for the customers to purchase. Then some software authors started providing copies via downloads from their website. These days you can visit a vendor website to download an installation file. Some vendors simply have you use the software on their website without the need to download anything or leave their website (ahem ahem SAAS)!

You can choose just one method of delivery eg only CD ROM (this still exists today), only installation downloads from the website to the users’ computer, or only allow entire software usage on a website so there is no need for user downloads (basically SAAS). OR

You can choose a combination of methods eg provide CD ROM for users but to complete the setup the user has to be connected to the internet to retrieve vital information from your servers (also useful for updates after CD ROM installation), installation file from the website that connects to the internet during the setup process, provide the user the software on your website but provide an offline mode so the user can use it without internet connection, provide installation via your website but also have a version that allows the user to do their work on your domain as well (Microsoft does this with MS Office where you can install the software on your computer but also use it on their website as well). Allow the user to install the website on their computers so when they tap the icon it opens your website (PWA basically).

This is Delivery, the part of technology scaling that finds ways of getting your software to the customers. The mistake people make with delivery is they jump straight to SAAS and close their eyes to various other methods of ‘Delivery’ (what can be learned or perhaps combined together). They jump straight to the server/infrastructure conversation without asking how individual users (and their activities) will exist on their domain.

The Delivery bit is where people start (and end) the scaling conversation, and it is so wrong! Imagine having a horse push a coach with you inside it. You keep beating the horse because you feel it isn’t pushing the cart properly and fast enough. That is what is happening today. For goodness’ sake the horse should not be pushing the cart!!

Do you remember the two spectrums from earlier? Side One and Side Two (the ones laid atop the foundation statement)? If the software vendors/authors followed the order of having a solid Core Code and then easing into an in-depth planning of Delivery, then actual distribution of the software will be easier thus achieving technology scale. This way the vendors will not be locked to one user (or a hand full of users) and targeted customers will not get stuck along their journey in using a vendors software product. This is valid for any type of software product across any business model (B2B, B2G, B2C, etc).

Most people have not understood the problem deeply and thought through how to put in place Core Code to address the problem and how in-depth Delivery plan will further support this Core Code. But they jump into talking servers/infrastructure (which is a small piece of the overall Delivery discussion). And it is usually in the line of: … a SAAS platform with adequate server instances ‘so they can scale’, let’s use microservices ‘so we can scale’. With the excuse of “moving quickly” many software authors have skipped critical steps that needs to happen, in favour of trends and buzzwords. It is terrible to watch.

To scale technologically you need to follow an ordered combination of Core Code + Delivery. Your Core Code first then the Delivery second. This is not a surface level conversation. You should have a deeper conversation into these areas individually and as a whole combination. This is what it means to have technology (at) scale.

I am interested in hearing your thoughts about my opinions on the scaling conversation. In what area do you disagree? Do you find it misleading or is it a great guide? Is there anything you want me to further explain?

In another part of this opinion piece, I might address another category of the scaling conversation, Business Scaling.

Don't do Product without Project!

H-J Johnson — Wed, 14 May 2025 20:26:10 +0000

Don’t do Product without Project!!

Don’t do Project without Product!!

In our ever changing world you are better off being results-oriented and methodical.

Whether you are working on a software, or a hardware, or a service or perhaps a combination of ALL three. Do not do one (Product or Project) and neglect the other! Do not leave out Product because of Project and vice versa. Be careful out there. Do your Project with Product. Do your Product with Project. One is NOT superior to the other. They both have their purpose individually.

Many newbies have never heard of the term Application Lifecycle Management (ALM) and it’s very sad for them. Many of these same newbies have never heard of or understood how SPM (Software Project Management) was meant to aid SE (Software Engineering).

Rather than trying to pit Product against Project or Project against Product, I am here to tell you that both can work hand-in-hand to achieve a successful solution to a problem.

Take my guidance, I have been here for quite some years now.

Learn to pick (and combine) aspects that is useful to you and works perfectly to your cause. If it works and is useful, go ahead and apply it. If it weighs you down, drop it. Your end goal is to arrive at a solution to an actual/existing problem!

Doing Product Management with Project Management (and vice versa) allows to be results-oriented and methodical.

📜 Read my stuff: https://lnkd.in/dUd5GasK
🤼 Follow H-J Johnson and hit 🔔
🔎 LinkedIn | Medium | Substack | DEV

Vibe coding, not the way, NOT the answer.

H-J Johnson — Fri, 25 Apr 2025 18:34:58 +0000

Vibe coding is NOT the answer and it will NEVER be the answer! With over eleven years in the IT space, I say that confidently. When I read about it, I knew it was another trend that will fizzle out at some point. Personally, I feel we should give the inventors of the vibe coding concept a point for effort. I mean that’s ‘e’ for ‘effort’, yes? We can all assume they were trying to help by creating something that will assist us move quickly and become better with our work, in this industry.

If you are building a technology offering, be it software, hardware, service or a combination of all three what you need is methods that are tested and battle ready. What you need is balance between thinking and action. Balance between theory and practical. Ask yourself: What and how are you thinking? And why are you thinking that way? What actions are you taking? How are you taking those actions and why? You do not want to over think or spend your whole time thinking also you do not want to over act or spend your resources moving in the wrong direction and doing the wrong things.

So now, how do you balance thinking and/with action? Where can you find and see this balance? How can you balance theory with practical? Does it even exist? I say, you can find this balance in the (battle ready, tested and trusted) Iterative and Incremental methodology!

This methodology does not neglect the SDLC. It uses it very well!!

Vibe coding is not the answer! Do this instead.

Allow me to give a very simple and brief look into what balance looks like.

THINKING & ACTIONS
THINKING:

Questions, ask questions! Is this a real/actual/existing problem?
Is this what I should be doing? ACTIONS:
Research! Things like: go out and talk to real people (surveys, interviews), focus groups.
Putting form to ideas. Things like: sketches, POC, Prototype.
IP Protection. Things like: patents, Copyright!
Actualising the idea beyond its first/initial form. Things like: MVP, soft launch, early bird access.
Integrated Marketing. Things like awareness, hype, whatever, PR, Sales.

THEORY & PRACTICALS
THEORY:

Statements like ‘technology makes work easy and smooth’.
Statements like ‘build it and they will come’.

PRACTICAL:

The theoretical statements above might not be entirely true in certain situations. You need some practical evidence to show what needs to be done!
Don’t build until you are sure people have the problem and will pay for YOUR solution. Talk to real people, do genuine research.
Practical design decisions such as: o Go completely electronic or have paper trails and paper backups. o Use Bluetooth, internet for communication, data transfer. o What will work here in this use case, in this operational environment? o Should there be offline mode and to what extent?
Technology in a certain use case/scenario/environment; is it really helping or is it hindering/slowing the work down. In areas such as restaurant management, auto shop management, farmers selling in the market, sending/receiving money in remote areas, making payment in remote areas.

This balancing act will happen as you go through the SDLC (Software Development Lifecycle) using the Iterative and Incremental Methodology. Several iterations (and increments) will occur as you use the SDLC until you are truly ready to face a larger audience and/or market to sell your product/solution.

Critical thinking is crucial. Situational awareness (and analysis) is very key to maintaining balance in a healthy way. With this approach you derive many benefits such as:

Avoid moving in the wrong direction.
Avoid building the wrong thing.
Overcome overthinking/analysis paralysis.
Gain proper System Design, Design Thinking, Service Design.
Avoid funds misallocation and mismanagement.
Proper documentation for actions/activities.

So, in summary:

Balance NOT vibing!
Iterative and Incremental methodology.
Utilise SDLC stages armed with critical thinking and situational awareness.

📜 Read my stuff: https://lnkd.in/dUd5GasK
🤼 Follow H-J Johnson and hit 🔔
🔎 LinkedIn | Medium | Substack | DEV

That’s not an MVP! NO, it’s NOT!!

H-J Johnson — Thu, 24 Apr 2025 06:07:40 +0000

Newbies in Product Management (and the IT/Software space as a whole) are being led astray. I consider myself to be blessed because I learned the correct fundamentals and basics on subject areas that are today misunderstood and misinterpreted. One of such subject areas is the concept of an MVP (Minimum Viable Product).

There is this image that is used to depict an analogy about MVP (Minimum Viable Product). There are several variations of said image, but I won’t dwell so much on the image, the analogy and all that is wrong with it. Why? Because I want us to talk more about the correct thing.

So, let’s understand. What is an MVP? It is the most basic, working and useable version of your idea that you can deliver within a set time for customers to use as solution to their problem not minding whether they have to pay or not and also gives you some chance to gain a foot in the market. An MVP is basic and it works better than a Prototype or a Proof of Concept (POC). Sometimes the gap between a Prototype and an MVP is wide, other times it’s just a small gap and in some (rather rare) cases the gap is so small you don’t even notice it.

To create an MVP, you first have to decide what it is that you are making/building. Is it software, hardware or a combination of both? Please note, you do not start building an MVP when you have not done proper research and feasibility studies to ensure what you are tackling is a real/actual/existing problem. During your research phase you use POCs and Prototypes to aid your research, feasibility study. Ok, so you have decided what it is that you are building, I usually advice at this stage you can (and should) still make sure what you are doing is an actual solution to a real/existing problem!! Now ask: What is the most basic thing your product can have that you can give to the customer as a solution? MVPs are not set in stone! MVPs are based on an understanding of the problem you are trying to solve, the situation you are in and the conditions that exist in the terrain or business landscape you are venturing into.

If your product is a scooter your MVP should be a basic version of THAT scooter!
If your product is a car your MVP should be a basic version of THAT car!
If your product is a wheelchair your MVP should be a basic version of THAT wheelchair!
If your product is a HR software your MVP should be a basic version of THAT HR software!
If your product is a fintech app your MVP should be a basic version of THAT fintech app!

By now you get the idea.

You do not start out trying to make a scooter and end up with a power bike. That is not an MVP!! NO, it’s NOT!! You do not start out trying to make a motorcycle and end up with a car. That is not an MVP!! NO, it’s NOT!!

All the stages you see in those misleading, misinformed, confused images are incorrect. MVP builds on lessons learned from your prototype and/or Proof of Concept during your research/feasibility study. Those lessons then translate into an answer to the question: What is the minimum that we can put together to give to the customer? Like I stated earlier it is not set in stone. Do a situational analysis, look at your research and the results of the research (POC and all). What is the most basic, working and useable state of the Product that you can deliver to the customer? Put those things together bring that basic, working, useable state into reality and that is your MVP!

Your MVP sets the stage for you to build newer improved versions of your product. Just ensure you stay close to the customer/users and continuously collect feedback. Compare the feedback with insights from the larger market/industry and you are on track to being a major player in your chosen field.

So, a quick recap:

MVP is a basic working, useable version of your product.
It builds on lessons learned from research, POC, Prototype.
You need to understand the problem very well.
You need to understand the market.
It is not set in stone.
You do not start out creating an MVP for one thing and end up with another thing!
MVP is a structure upon which to build newer, improved versions of your product.

Hopefully, this simple explanation clears the misinterpretation of what an MVP means. And you never have to worry about its true meaning.

📜 Read my stuff: https://lnkd.in/dUd5GasK
🤼 Follow H-J Johnson and hit 🔔
🔎 LinkedIn | Medium | Substack | DEV