All around us, we see a lot of products, supposedly built to fix lots of problems. The world we live in keeps conjuring up solutions for diverse problems. A significant component from amongst these problem-solving movements is technology. However, it is essential to note that it is the people, humans, who are behind building the technology. People take up different components and use various technologies to deliver a solution known as a product. The process of coordinating people and technologies in a clear and strategic direction towards creating and delivering a value-adding product to an audience (market) is what we know as Product Management. Well, at least that’s some of it. Product management is admittedly a lot more. In the delivery of a software product, the traditional life cycle is driven by product management; but it does not stop there. While this article converges on the B2B space, I do hope to shed more light on some general concepts of product management before zeroing in on the B2B space. First, let’s look at some product management myths.


Here are some misconceptions about the product management role;

It is exclusively technical: As I mentioned earlier, product management is NOT exclusively a technical role. I use the word ‘exclusive’ because technical understanding is vital. However, it is not the only requirement. In fact, an argument can be made from a business mindset; that people skills take prominence for technical understanding.

Product management = Project management: A project manager is concerned about much more than the product as indicated by the knowledge areas of project management. It is important to note, that the product manager actively provides a considerable amount of the information that the project manager requires for her/his activities. For example, while the timeline should be top of mind for everyone, the project manager is the ultimate ‘moral compass’ and is expected to hold the product manager accountable for this. It’s all about requirement specification sheets: Well, it isn’t about dreaming up unrealistic features on paper. As a product manager, you must deliver those functionalities. After all, you are in the best position to inform what’s possible or not.

You are the queen/king of the timeline: Product managers do not conjure a timeline, or at least they shouldn’t. While they can estimate from experience, product managers always need the (engineering) team to agree on deadlines. In reality, constraints might require the product manager to submit more stringent timelines, but it should be with the team’s buy-in.

It’s all about strategy: There is this idea that product management is very high level, that there is no need to focus on the details. Very wrong. While the product manager is concerned about the outcome, this is only delivered by focusing on the details.

It’s super easy! Is product management fun? Absolutely! Easy? Not quite. The exciting thing is that you are at the mercy of your team for the most part. While having a clear view of the task at hand is vital, they are being executed by others, and it is essential to remember that they are people and people are complex creatures. In short, product management will test your people skills.


According to the product plan, product management is “the practice of strategically driving the development, market launch, and continual support and improvement of a company’s products.” You might wonder why non-technical concepts are being mentioned in a seemingly technical conversation. This is because —as I mentioned earlier— product management isn’t exclusively a technical role. A product manager’s job isn’t just to deliver a product. It is also to ensure that the product has a clear target and meets that target. But this target is usually a function of its use in a place called a market (customers; individuals, businesses, e.t.c). This brings me to the three most crucial components of product management;

The product management cycle

Business: The product manager must know the business perspective of the product. Some questions he/she should be able to answer include;

  • What market are you playing in?
  • Who are your competitors?
  • Who are your client’s competitors?
  • What’s your value proposition?
  • What value are you deriving from this execution?

Technology: It must be said that technology must always remain a means and not the end in itself. While it is essential but not to be fixated on, the product manager must be aware and conversant of the technologies being utilized in the delivering of the value proposition. Questions to be answered include;

  • What technologies are being deployed?
  • Is this the most efficient way to execute?
  • How can it be improved?
  • What are the possible challenges?
  • Any trade-offs?

People: People here refers not just to your customers/users but also your team. Product managers must be human-centric. Some questions to be answered include;

  • Who is the audience?
  • Who are the key decision makers?
  • How interested is your team in the product?
  • Are they personally vested?
  • Is it just another ‘code’ to be written?


The product manager is responsible for the success of the product; but what does this mean in terms of responsibility?

  • Research.
  • Requirement gathering.
  • Feature definition.
  • Liaising with the relevant departments.
  • Communication.
  • Managing execution.
  • Processing feedback in a way that the team can implement.


The term ‘B2B’ refers to a commercial transaction between two organizations, typically one being a service provider and the other being a client and or customer.

How similar is it to B2C and at what point do they diverge?
B2B product management is similar to its B2C counterpart in the following ways; There is always a customer (individual/organization), just different approaches There is still a value proposition; whether to one or many. You are either selling the same thing or different ‘semi’ value propositions to different people. However, it differs in the following;

  B2C B2B
Sales Approach Buy-in of one Multiple buy-in
Market Mass Appeal Niche
Customer Individual Organisation
Monetisation Small, recurring Lump sum, could include recurring support charges (the B2C model can also apply; think Slack, Asana, e.t.c)
Rationale Emotional, could be a ‘nice-to-have’ Process driven, usually logical
Relationship Brief, unpredictable Long term (seen as a partnership)
  • Sales approach: In B2B, there are usually different stakeholders that influence the buying. This means multiple buy-ins are required while in B2C, you need a buy-in of one. (Buy-in does not always mean that the decision to buy rests with the individual).
  • Market: B2B products are in a way, specialized (niche market) while B2C products are usually open to multiple iterations which are subject to what users want (mass appeal).
  • Customer: The B2C customer is usually an individual while the B2B customer is an organization (generally with multiple internal customers)
  • Monetization: With B2C, the customer will likely pay small and recurring charges based on what they intend to use. However, with B2B, the organization will pay for the entire product irrespective of what’s used or not.
  • Rationale: B2C products may or may not be an obvious need for the customer. They generally look good and gives the customer the impression of an obligation (there can be a genuine need) triggering an emotional buying decision. On the other hand, B2B products come into play because the organization believes it has a critical problem it needs to solve. There is an emphasis on process and logic.
  • Relationship: B2B transactions tend to build partnerships where the provider can potentially become the go-to person for any related services. With B2C, it is more unpredictable and usually brief. There is always a need to capture the attention of the customer.



SDLC Stage Department Activity
Requirements Client service Engineering/Product Engineering - Requirements Gathering
- Understanding the problem
- Research
- Analysis
- Planning
Design Client Service Engineering & UI/UX - Software Requirements
- User Interface Design
Implementation UI/UX (Interface Development)
Frontend Development
Backend Development
- HTML/CSS Implementation
- Frontend Implementation
- Backend Implementation
- Graphics (if any)
Testing Quality Assurance - Basic functionality testing
- API functionality testing
- Code reviews
- Performance testing
Deployment DevOps - Dev, Staging, and Production environment setups
- Code deployment
Maintenance All - Availability
- Code Maintenance
- Software Updates