February 19, 2021No Comments

What’s the Difference: B2B and B2C Product Management

In this article, we talk about the differences and similarities between B2B and B2C product management. You will also learn about the job responsibilities of B2B and B2C product managers, and how to switch from B2C to B2B projects. 

In their article “Product managers for the digital world” McKinsey&Company call product managers “the glue that binds the many functions that touch a product— engineering, design, customer success, sales, marketing, operations, finance, legal, and more. They not only own the decisions about what gets built but also influence every aspect of how it gets built and launched”

It’s hard not to agree with this definition. Both B2B and B2C product managers are responsible for leading their products throughout their lifecycles. However, their daily responsibilities may differ due to the specifics of the business. 

So let's start at the beginning and briefly define business-to-business and business-to-consumers product management.

What is B2B product management?

Generally speaking, a B2B product manager focuses on the clients and their needs. In B2B, companies have longer relationships with their clients. You give a client software ownership instead of keeping it to yourself. It’s also worth noting that when you work with big B2B contracts, you can suddenly have 10k users come to your platform. That’s why it’s a bit different the way you measure and compare usage. 

As a B2B product manager, you spend most of your time in customers meeting/calls and working closely with the sales team.

What is B2C product management?

In B2C, product managers focus on the end-user without knowing their customers. To obtain any data about customers and their preferences, product managers can hold focus groups, conduct surveys, interviews, and user research but they don’t need to have ongoing relationships with the customers. On a daily basis, B2C product managers work with product analytics, study user behavior patterns to see what works well and what should be improved, and continuously seek new ways to optimize product UX.

The Difference Between B2C and B2B

Despite the differences in project management, sales processes, and release cycles, both B2B and B2C have one thing in common, and it's to anticipate customer needs and solve them. Eventually, no matter what you think of a certain idea or feature, it matters what your customers need. In both cases customers want:

  • User-friendly and outstanding onboarding experience. 
  • The mobile-first solution that makes it easy to interact with the product on the go. 
  • Personalized solutions. According to Accenture, “With so much digital “noise” out in the marketplace, companies must make the most of every opportunity they have to connect with customers. The priority? Solving for individual needs and preferences – with the customer experience right at the center”.
  • Low level of effort no matter where they are in their buyer’s journey.
  • Brands that deliver on their promise and values as most customers buy from companies they trust. 
  • Support channels with multiple options including calling or chatting with customer support or reading FAQs.

Although there is plenty of overlap between B2B and B2C product management, they are two distinct entities, with different processes and approaches. To help clear the confusion, let’s look at the major ways in which they differ:


It’s not the product manager’s role that makes B2B and B2C different. It’s more the nature of the customers. Let me briefly explain what I mean:

B2C products are consumer-facing and help users solve their personal needs. Social networking apps (Instagram, Clubhouse), or health and fitness apps (Strava, Headspace) are all examples of B2C products. In B2C your focus is more on the end-users as you build the product for one key persona - your user. It simplifies the task, but, unfortunately, not everything is as easy as it seems, since some users can be hard to understand. With B2C products, managers can’t reach every individual user and ask for their feedback. For this reason, the product scope usually originates from analyzing user behavior patterns, identifying some gaps and creating vision through user research, and adapting to the changing needs of the users. 

On the other hand, with B2B products, you focus on the client and their users. In other words, you build products for two personas: those who make purchase decisions (your customers) and the product users (your customer’s employees). That’s why balancing between the needs of the two personas in your product roadmap can be challenging. 

B2B products are business-oriented and are intended to solve business problems. For example, CRM platforms (Salesforce, HubSpot) or cloud providers (Amazon Web Services or Microsoft Azure) are all examples of B2B products. B2B is typically sales-driven. That’s why, product managers need to understand the sales process, client requirements, and how leads are generated. It will help them to develop more effective solutions and convince the team and stakeholders to change focus (if there’s a need for it) and adjust the digital product development process accordingly. 

Related Article: Digital product strategy: from idea to execution


Exciting and brand-new features are great unless it concerns your job and getting things done. This is what determines the speed and scope of making changes to your products. Let’s consider the two categories separately: 

Releases for B2B products

In B2B software, customers are not big fans when it comes to frequent changes in product functionality. The reason is that changes might cause some product malfunction. The introduction of new features may also require additional testing and staff training, which can take some time. 

To mitigate any risks related to product performance, product managers usually put together all major releases. They try to make product updates optional or based on settings, while avoiding changing the entire product experience at once. 

Releases for B2C products

For B2C customers, things are opposite: small and frequent updates are welcomed. Users are happy to try new functionality and engage with the product on new levels. But it’s important to remember that when introducing new features, one should prevent any performance problems. If your product is introducing some serious updates or UX changes, consider user onboarding or some hints so users can easily start enjoying the new features. 


In B2B the person who decides to buy is not usually the person who is going to use the product. In B2B you have many ideas coming from stakeholders on how to improve the product. Product managers have to take into account different stakeholders, prioritize the product scope, and keep stakeholders informed of progress. That said, when you release something new, it's the product manager’s job to communicate with all stakeholders and ensure that the product addresses the needs of each one.

On the contrary, for most B2C products, the decision-maker and the user are all the same person. 


B2C product managers are focused on building products that appeal to users emotionally. Research conducted by Bain & Company “The B2C Elements of Value” shows what consumers value most by highlighting four categories of elements such as functional, emotional, life-changing, and social impact. At the bottom of the pyramid, there's a need for users to meet their functional needs and become more personal, at higher levels.  

In B2B product management, your main focus should be on improving workflow efficiency. Building new features, adding new functionality is more important for enterprise clients than worrying if the product has an appealing interface. 

The same study as with B2C customers was conducted with B2B. It turned out that the bottom of the pyramid shows the most objective values such as price, regulations, scalability, quality, etc. On the top of the pyramid, the elements become more subjective and personal like design and aesthetics, perks, vision, marketability, and so on.

What B2B & B2C Product Managers Have in Common?


According to Gartner, 80% of product managers state that they use basic tools that help them to “solve digital product management problems, make data-driven decisions and accelerate end-to-end product management processes”.


Gone are the days when UX was a nice-to-have for most SaaS products. Nowadays, a compelling UX is a new black and oftentimes a key competitive advantage of the product. And this applies equally to both B2C and B2B companies. 

B2B products have much in common with B2C ones: they need to create a clear information architecture, add engaging and informational content, provide details about products, and have a simple, clean, and friendly interaction design. 

How to Transition From B2C to B2B and Vice Versa

The best way to learn about career prospects and the specifics of switching from one business to another is firsthand. Learn about Katarina’s experience of working with both B2C and B2B businesses. In this podcast, she shares some of the realities and myths of being a product owner in both.


B2B and B2C are different when it comes to releasing cycles and roadmaps, customer acquisition, and stakeholders' involvement. But despite all these differences, one thing remains common and it is the most important one in the entire digital product development process - you create and build for humans. What matters most is that your product has to be usable. Therefore, always strive for a better, intuitive, clear, and smooth user experience that will take away all customers’ frustrations, add value, and make them enjoy your product. 

If you need to figure out how to improve your digital product development process, conduct user interviews, make prototypes, verify your ideas, and prioritize features, our digital strategy consultants will provide you with all the necessary resources and support.

If you're looking for a reliable team to build your product, we’re here to help. Share details of your project, and we’ll contact you asap

February 25, 2021No Comments

Product Drama Podcast #7: Why You Need a CTO?

Listen to our new podcast to learn why you need a CTO in your company and what are their main responsibilities in product development.

Companies become bigger and transacting faster. All of their legacy methodologies and ways of operating now need scale. Decision-making isn’t done in isolation anymore and organizations hire individuals who understand the problem and make decisions on the problem. A CTO is a person responsible for setting a technology strategic vision, assembling a team to solve tech challenges, and keeping the company running. 

CTO is short for Chief Technology Officer, or, in other words, a person who wears a lot of hats in the company. 


A CTO, at its core, is the executive responsible for managing and realizing business value from technology across the company. The job of the CTO is to work with the CEO and other business leaders to ensure that you’re implementing the technology vision that supports the digital product strategy of the business. 


The role and responsibilities of the CTO may vary across companies and industries. But one thing remains the same for every CTO: they have to stay up-to-date with the latest trends and technologies that could disrupt their business. 

In general, the main tasks of a CTO include:

  • Developing a technology strategy and vision. 
  • Building, hiring, and guiding technology teams.
  • Empathizing with employees and guiding them in the period of uncertainty and confusion. 
  • Understanding how technology can help achieve company goals.
  • Working with senior stakeholders, and other c-level executives to determine values and mission, and plan for short and long-term goals.


The chief executive officer role has been around for decades. However, the job CTO in 2021 is not the same as it was in 2010. The CTO’s main concerns in 2010 were backups, desk support, and managing IT infrastructure. Nowadays, it’s a more strategic role: building a roadmap, guiding the team, and communicating the technology vision across the company. 

Peter Shankar, Chief Technology Officer at Equity Multiple, joins the new episode of the Product Drama podcast to share his story and experience of what it takes to be a tech c-level executive in the real estate investing company, and what his job looks like day-to-day. 

This episode will be especially useful for companies that are thinking of adding a CTO to their team, as well as for those who dream and plan of landing a tech executive role one day. 


February 18, 2021No Comments

PRODUCT DRAMA PODCAST #6: Fails and Wins of Launching Products

In this episode, we talked to Mary Kopczynski, CEO at RegAnalytics about what it's like to launch a RegTech product, fail forward, and turn mistakes into stepping stones success.

The first company that Mary created was called 8 of 9 (as she is the eighth child out of nine). She then did the regulatory crisis management for the biggest banks on Wall Street. 

It took her several years and failed products to come up with RegAlytics and realizing that she is a truly successful entrepreneur.

This is a jam-packed episode. On one hand, we talk about things that seem boring at first sight, like regulatory compliance and laws. On the other hand, we discuss  ups and downs, finding strength in yourself, and continuing to create what you believe in. Mary also mentions the practice of handwriting and what benefits it can bring to your daily routine.

We also covered:

  • What is RegTech and what’s its future look like?
  • How to launch your product, while keeping your day job?
  • How to build a simple MV first and start collecting customer feedback asap?
  • What are the founders’ biggest fears?
  • How to test product concepts and conduct customer surveys?
  • Tips for startups who are afraid to fail.
  • What does it take to be a cool manager?

Here are some quotes:

“You can’t say you’re building an industry. You’ve got to build something someone got to find useful”.

“Another mistake was that we built products and never showed them to anybody”.

“Founders don’t rest. And that’s another pitfall”.

“When you’re early in your failure, it stinks a lot more”.

“People at your company are not here to be your friends. They are at the company to gain valuable skills”.

Check out:

Good to Great: Why Some Companies Make the Leap...And Others Don't 

Morning Pages


Find Mary on LinkedIn

February 11, 2021No Comments

Product Drama Podcast #5: Shape Up Method

In their latest book, Basecamp introduced their internal approach to product development. It was described by Ryan Singer, Head of Product Strategy at Basecamp, in the book Shape Up: Stop Running in Circles and Ship Work that Matters

Singer writes, “one of the core tensions in product management is the urgency of day-to-day implementation details vs. the necessity of strategic planning. Left unresolved, this tension leads to a slew of practical problems (missed deadlines, tangled codebases) and low morale.

As the team started to grow, Basecamp spotted some challenges that led the company to seek new ways to address these pains. For instance, lack of clear understanding of the project endpoint, no time for strategic sessions, the ability to ship products on time, and meeting stakeholders’ expectations. This led the team to come up with their approach to product development.

What is the Shape Up Method?

The Shape Up Method is the so-called tool that is used by product development teams to shape, bet, and build products. It gives product teams certain techniques to better define and prioritize projects, and address risks at each stage of digital product development in order to build and ship better products. 

This method turned out to be super effective for the Basecamp team. But what about other organizations? 

We talked to Vi and Canaan from Careerplug, a recruiting software. In the new episode of the Product Drama podcast, they shared how to work in a team with no product managers and start applying Shape Up in your company - so that you can optimize the development process and improve team communication.

Must-listen moments

2:20 - How to organize the development process with product managers?

Vi: "When we did have Agile and were practicing it, none of us felt that it was our natural inclinations. We were feeling better when we were working together, as closely as possible, which Shape Up allows us for. With Agile and product manager in place, we felt like we had that one person to manage every of the work that we were doing, and how it was done, which kinda muddied the waters for us. And we like the idea of working closely together, especially the designers and developers". 

6:06 - What does a pitch in Shape Up look like?

Canaan: "It generally encapsulates a proposed solution, an appetite, which is how long are we going to stay working on this, and kinda like boundaries sets like where we are not going to go. Instead of saying “we want to implement X, how long will that take?” We kind of switch that statement around to say “here’s a problem that the business is facing, how much time are we willing to spend to solve that problem?” 

13:28 - How to work without a backlog?

Canaan: "That allows us to not lock ourselves into the concept that we certainly have to do this, as we haven’t gone to it for six months, and we are going to do it now anyway. So maybe these six months from now the thing that we were potentially talking about means nothing for us. It allows us to change quickly".

23:45 - How to avoid the most common mistake when writing pitches?

Vi: "We’ve been learning up with pitches that require a ton of discovery work within the cycle period. So when the team should be focusing on building up the solution, and figuring out what is deliverable within six or two weeks, they are suddenly stuck with defining what the solution is all together, instead of pairing it down and delivering something. So I think that was one of the biggest mistakes".

31:08 - Tips for those who want to start with Shape Up.

Canaan: "Be open-minded and non-reverse to change".

To listen to the entire episode and learn how the team from Careerplug managed to optimize their processes with the help of the Shape Up method, click the video below:

Check out:

Shape Up book

Vi on LinkedIn

Canaan on LinkedIn

February 5, 2021No Comments

Product Drama Podcast #4: From Idea to MVP

For this episode, we met with the Defynance team and learned how to go from the idea to MVP development and get the first investment.

  • 1.6 trillion dollars is the amount of the student debt crisis in the US. 
  • 45 million people have student loans. 
  • 70 % of people who leave college have student loans (on average, it's 30 thousand dollars per person). That’s like a BMW 3 series. 

From that perspective, Farrukh Siddiqui, founder, and CEO at Defynance wanted to tackle this problem. He was obsessed with finding solutions that are not based on debt. Together with his team, he discovered the concept of an income share agreement

But it’s not debt because a person doesn't have to pay a certain amount of money back. It’s just to share income for a certain amount of time. 

So they started working on that concept and noticed that universities like Purdue and Coding Bootcamps were using it. But no one was using it to refinance student loans. 

This idea became the starting point to creating the first fintech to refinance existing student loans using a smart income share agreement (ISA) that is debt-free. 

In this episode, we’ll learn how to go from the idea to MVP development and get the first investment. 

Tune in to learn how the Defynance team:

  • did PoC before proceeding with MVP?
  • defined scope of MVP?
  • picked up technology stack and prioritized features?
  •  educated users and made them trust to start using the platform.

And more!

As usual, this is a great episode you won’t want to miss.

If you struggle with how to go from idea to creating the first version of your product, you’ll want to get this episode into your earbuds as soon as possible. 

Click on the video below.

January 29, 2021No Comments

Product Drama Podcast #3: B2B and B2C

The role of a product manager is largely the same across both B2B and B2C businesses. However, there are also some differences when it comes to digital product development process and communication with the team. Our guest today will help clear that up a little bit.

Katarina Seach is a Product Owner at Qollab, where she’s responsible for B2B online learning platforms. Katarina worked with both B2C and B2B businesses, and we thought she’d share some of the realities and myths of working as a product owner in both.

Needless to say, she knows her stuff.

In this week’s conversation we talked about:

  • challenges from transitioning from B2C to B2B products;
  • ways B2B and B2C product management are actually different and similar;
  • communication and motivation in the workplace;
  • methods to prioritize features;
  • release cycles and enablement;
  • women in product management.

We hope you enjoy our talk! Click the video below and share your thoughts in the comments.

Find Katarina online

Stuff we mentioned:

Women in Product

January 25, 2021No Comments

The problem with product strategy and how you can fix it?

In this blog post, we'll define product strategy, the difference between feature-based and outcome-based roadmaps, and how to measure outcomes to make your team more effective.

For most of our life, we strive to achieve some goals. If we want to look at our best physically, we go to the gym and start eating healthier. If we're going to climb the proverbial ladder in our career, we start educating ourselves, enroll in a course, or find a mentor. These goals consist of small and tangible milestones. But they are not our ultimate purpose and what we want to achieve in the end. 

Buying a bicycle is not an outcome. A bicycle is just a means of transportation, an opportunity to spend more time outdoors and keep yourself in better physical shape. But these are all examples from everyday life. Getting back to our topic, what does it have to do with product development? 

The moment you need to decide on the digital product strategy and the roadmap, it's getting hard to outline the desired outcomes. In this way, it's more tempting to make features the core of the product strategy as they are much easier to measure and deliver. But what if we shift our focus and make our strategy document more than just a set of "nice to have elements"?

Output, outcome, and impact in product strategy?

Have you read a book by Joshua Seiden, “Outcomes over outputs”? If not yet, I highly recommend it. This page-turner will take about an hour of your time but give you a couple of useful insights. 

In this book, the author explains why and how to move from “making stuff” to creating outcomes by changing customer behavior. Seiden defines an outcome as “a change in human behavior that drives business results.”

Let’s take an example of an analytics dashboard for company CEOs. Imagine that there’s no need for a product team to regularly create reports for a company's CEOs so that they can see the most important business data at a glance.

Output - analytics dashboard for company CEO. 

Outcome - product managers spend less time collecting data to report to the CEO; the CEO has access to analytics at any time. 

Impact - the company doesn't waste time and resources to perform routine tasks like creating data reports for the company CEO; the entire organization works more efficiently. 

Inspired by this book, I’ve decided to take it as a basis for this article and explain how we perceive and practice outcome-based software development when creating a product strategy.  

Related Article: Digital product strategy: from idea to execution

What’s wrong with the feature-based roadmap?

The feature-based roadmap consists of a number of features to be delivered within a specific period (weeks or months). In other words, it gives the product team and stakeholders visibility into how long it will take to develop certain product functionality. 

It looks nice, neat, and very structured. Like this:

But the main problem with a feature-based roadmap is that it rarely works in practice in terms of product outcomes. 

It’s true. Have you ever met a product team that created a feature-laden product development strategy and stuck to it without any overtime, meeting all the deadlines, and, most importantly, delivering everything as it should be? If yes, please share your secret sauce. 

A recent research project turned out that 80% of features in the cloud software product are rarely or never used. The result: about $29.5 billion is wasted. And we’re talking only about cloud software. Imagine a more large-scale impact. 

Before developing another feature, ask yourself: “What will people be doing differently as a result of this feature?” Unfortunately, the product teams ship a feature without analyzing its performance and value.

The main reason why a  feature-based roadmap fails is that it lacks the answer to one simple but crucial question: Why?

Why did your company decide to create this product?

Why should people care about your product?

Why should your customer pay for the product?

As a rule, this approach is not much like predicting whether these features deliver any impact. 

You can create a beautiful app in terms of interface design, convenient and intuitive in terms of good user experience, develop it using the latest and most trendy technologies and still not deliver any value to your customers. And if the product (hence the features) doesn’t provide any value, then it follows that we shouldn’t consider features the center of our strategy. 

The goal of an effective product development team is to create an impact and work on outcomes. It requires us to shift focus from thinking in terms of high-level tasks and work on smaller and more manageable targets. It leads us to a different approach to product development, which is an outcome-based roadmap

Related Article: Product development backstage: start new projects faster

What are outcome-based roadmaps?

Outcomes should be the reason you decided to develop a product strategy. Let's imagine you're thinking of redesigning your website. You set a task, "redesign a home webpage." But why did you decide to allocate resources and time working on that? Maybe, you've received feedback that it's hard to navigate the page or discovered that visitors don't scroll down the page. In this way, the real reason you want to redesign your home webpage is to increase customer retention rates

Now, let's suppose if a redesign operation failed? I mean, what if your visitors still abandon the website and don't fill in the contact form? What is the design that wasn't the problem at all? But the main reason why the visitors leave is poor content, product pricing, or a confusing registration form? Would you continue with the redesign as the best solution for this issue, hoping for the best? I guess not. 

You'll continue to test assumptions, gather feedback, and analyze the multiple scenarios. Outline the business problem (outcomes) and then decide on the features' details (your outputs).

Schematically, the difference between feature-based and outcome-based roadmaps looks like this:

If you face the fact that you cannot accurately answer the question “What’s the outcome for my product?” don’t panic. Think about why you initially wanted to create this product? What do you want to build? Why should customers use the product? In other words, develop your product around how to help people. 

An outcome-based strategy acts as a link between your product vision and the problems you will solve to achieve this vision. 

This roadmap shows what we are doing and why; what results we are going to achieve for company stakeholders. 

For your potential users, this is a so-called specification, where you explain that you know that there’s a kind of gap (problem) in the market and how your product will help solve it.

Measuring Outcomes in Product Strategy

The outcome is less measurable and quantifiable than the output. It’s easier to say, “We wanted to build a gas station, and now we have a gas station.” But when your desired outcome is like “deliver technology that solves complex problems in a beautifully uncomplicated way.”, how would you start measuring it?

The answer is the Objectives and Key Results (OKR). This method was invented and first used by Intel. Google, Oracle, LinkedIn, and Twitter picked up this method later. OKR helps to focus on goals, increases initiative, and stimulates work between different teams in the company.

Consider the Objective as a mission statement but for a shorter period. The Objective should be qualitative, time-bound, and actionable. 

Key Results help you to quantify your motivational Objective, make it measurable and possible to achieve. In other words, Key Results help you to know whether you met your Objective. 

In a nutshell, an objective answers the question “Where do we want to go?” while a critical result gives an understanding of how we will know we’re getting there. 

Let me give you an example:

Objective: Increase the efficiency of all processes. 

Key Result 1: Introduce new tools and techniques by Q3 FY 2019-20. 

Key Result 2: Conduct training sessions about new tools and techniques by Q2 FY 2019-20.

Key Result 3: Organisational productivity increased by 45% by Q4 FY 2019-20. 

The primary purpose of OKRs for agile product teams lies in its promise for improving the way we work. 

Deciding which features to build and how to prioritize them

Now that the product has target outcomes, the product manager can decide which features will help them achieve their goals. Start with defining the priority of each feature so that to form the right backlog. 

For starters, answer these questions:

  • Will the feature help us attract new customers?
  • Will this feature help attract new paying customers?

Then, divide features according to their importance: critical, high, medium, low.

In this way, you will see a bigger and more precise picture of what you want to be global, up to the product functionality that will help you with it. 

An outcome-based roadmap won’t drastically change your product development strategy. But it will help your team become more organized and get a clearer understanding of what your company wants to achieve within a specific project. 

When you focus on final results and not deliverables, you get:

  • Better visibility of your target goals. 
  • Ability to plan and prioritize based on your value. 
  • Clarity among project stakeholders and product team. 
  • Space for continuously receiving user feedback and an opportunity to adjust the product accordingly. 

Closing Thoughts 

As a product manager, your main focus should be on the outcome of a product, not the output. That is to say, you may conduct 10 user interviews, collect all possible feedback, and assemble a team of great designers. But it won’t matter until your final product solves the problem. 

Let’s talk about how your company can benefit from an outcome-based product roadmap. 

December 22, 2020No Comments

Product Drama Podcast #2: Building empathy with users

A product manager at ParkMobile and Agile coach Toby Johnson is our guest for the second episode of the Product Drama Podcast. It's hard to describe in one or two sentences what this podcast is about.

We talked about a whole range of things: from product development challenges and choosing the right tech stack to team culture and the importance of clear communication between product managers, developers, and key stakeholders.

To better understand how versatile and awe-inspiring this episode is, read some quotes from Toby:

  • “Building software is always about trying to do the same smallest possible thing as quickly as possible, getting it to market, testing it, and building on top of that.”
  • “The smaller you start, the faster you make a decision.”
  • “If you try to stick to this ideal one-size-all solution, it conceptually makes sense, and it is very romantic and idyllic. In practice. I have never heard of it.”
  • “It doesn’t matter how your roadmap looks. It matters how people will use the product.”
  • “And the only way to get people to use the product is to try people use this product.”
  • “If you can get someone to test drive the software, you will be more likely to realize what they don't like about it or what it needs, and people will be more likely to adopt it.”
  • “One good way to check if the features are important is to tell people you are going to remove them.”
  • “Don’t ask people what the most important features are. Ask them what are the ten things they will quit?”
  • “Stop treating people like computers, treat them like emotional human beings, who make emotional decisions.”
  • “As a product manager, the biggest thing that you can do is to reduce the risk of any product.”
  • “Take the ego out of product management.”
  • “Communicate what and why you build.”
  • “Product management is a lot of homework.”
  • “Be empathetic. Don’t treat one developer the same as another.”

This episode should not be missed. To hear and watch it, click the video below and enjoy!

Here are some key timestamps:

0:00 Introduction. About ParkMobile

14:35 Conceiving New Products

19:29 User Research & Testing

30:56 Replatforming

38:14 Roadmapping

53:27 Working with Devs

1:07:12 Top 3 PM Skills

If you've missed the first episode, you can watch it here.

December 15, 2020No Comments

Product Drama Podcast # 1: Launching an internal product

For our first episode of the podcast for product managers the Product Drama, we invited Harshil Paliwal to talk about the specifics of internal product launch and business process automation challenges.

Here's what we covered:

  • how to help employees see the benefit of work automation?
  • how should workplace culture adapt to automation and transformation?
  • how to find the right DevOps tools for your team?
  • what is the importance of detailed project requirements?
  • how to motivate employees to adopt new technology?
  • what are the challenges in launching an internal product?
  • how to train the team on Git?

… and more.

Harshil also shared her valuable lessons learned as a product manager:

When it comes to motivating people to start adapting new processes in the workplace, show, don't tell. Once you show how easy those tools can be, the more willingly the team will start using them.
As a product manager, explore and research as much as you can. The requirements have to be crystal clear. Requirements engineering is not boring, it can be fun. Even if you planned everything carefully, something can go wrong. And it's okay.

Click on the video below.

The stuff we mentioned on the show:

International Institute of Business Analysis (IIBA)






View Harshil’s profile on LinkedIn

Full Transcript:

Anatoly: Hi. This is a podcast about effective remote product development. This is Kate.

Kate: And this is Anatoly. Hi. 

Anatoly: And today we'll talk about the specifics of launching a new internal product. 

Kate: Today’s guest is Harshil. She is a product manager at Fitsurance, and Harshil will share her story with us. Hi Harshil

Anatoly: How are you doing?

Harshil: Hi, guys! I'm doing good. Thank you. 

Anatoly: So, would you please introduce yourself. Maybe we've missed something?

Harshil: Of course, yes. Hi all! My name is Harshil. I am currently doing my masters in business informatics at Utrecht University. However, before this, I have worked in the industry for four years, during which I managed two projects. I worked as a software developer and eventually I moved to the position of product manager. And, yeah, here I am, telling my story. Currently, I am also a part-time product manager at Fitsurance. 

Kate: Can you share a little bit more about the project we are going to talk about today?

Harshil: Sure. So that project that we built in my previous company was an automation project where we tried to bring in a lot of DevOps tools to automate the whole deployment cycle to be precise. So it was a closed tool, which is used in the company to make budgets, do forecasting, and all finances. They had a lot of scripts within this closed tool and we tried to implement a lot of repository management and version control, and all those principles into it to automate the whole thing. 

Anatoly: Can you share more about the goals of the project? Why did your company start it?

Harshil: So, the main aim of the person who started it was to bring in the culture of automation. A lot of tasks we were doing manually. We had two different teams. One was a full-on built team who used to code, code, code. And one was a full-on support team, which used to deploy all the applications into the production environment. So just like we had dev tested the product, we had those environments in our company too. But you know what happens across the environments it is too complicated to maintain consistency and whenever the person is deploying something, it is an all-day task and you have to look at so many variables, maintain so many things, and sometimes this is failing, and that is failing, and at times it happens that when you deploy something and it fails you try to fix it on the spot. So the consistency is lost in that process and the one thing that is not the same across all the environments, so is what we wanted to change. We wanted to bring in consistency using automation.

Kate: So, basically, you’re talking about process automation, right? Sounds very familiar, because I remember that about a year ago you were talking about process automation in our company, right? You see, I’m not a technical person, so it’s very interesting for me, why is there so much buzz around the process automation thing in the company?

Anatoly: I can share my story. I was running all over the office trying to engage people and “join my side”. I was impressed by some TEDx videos, and I thought: “This is a good thing that we can have with our clients and help them save more money in the long run. It’s a good one when you do a long project, not like a three-month thing, but many many years and it starts paying off quickly. The more you work on the project, the more you save. 

Harshil: Actually, that is so true. You can’t set a date when this whole automation is complete, because it just happens as you move with the processes. So you build a small feature and then you try to improve that feature and build more features on that existing feature. So, yes, it is like Anatoly said, can’t be quickly laid. It can be quick but it just goes for years and years. You can’t just say: “oh, it’s just for two months”. It can’t just happen like that.

Anatoly: Can you share a little bit more about how you guys prepared the requirements? Because it's a  long process that involves lots of parties. 

Harshil: Oh yes, of course. Requirements engineering is one of my favorite parts of product development. People find it boring but it's the most fun when you go around and talk to people and understand what their problem is. 

So, as I told you, the tool used to do multiple things like budgeting, forecasting, and different things. So, we had five teams using this tool across one set of teams. And we were forced to select one team for them and we made a huge excel document, wrote down all the features that needed to be automated and it took around three months. After that, we researched what DevOps tools we wanted to use because there are so many tools these days. For version control, we had Git, Mercurial, SVN, Perforce. Oh my God, it’s just overwhelming and you just need to narrow down what you want to use, where do you want to use it, and prioritize everything. So, yeah, that’s just how we went, we just went to the manager of each team, wrote down the requirements in that big excel sheet, and prioritized our requirements according to the conversation that we had with the managers.

Anatoly: Would you mind sharing what tools have you stopped in?

Harshil: There were some tools that we're compliant with the company, so the company had a list of tools, which we can use, and which the company license allows us for. So we used Git for version control, and then we used TeamCity to build automation. Then we used Nexus for our repository management and Nolio for the ultimate deployment of code into the production environment. So there were the four main tools, and then we were exploring some more but then things happened… So, yeah, you just keep exploring.

Kate: By the way, you, as a product manager, what tools do you use daily? What tool would you recommend? 

Harshil: So the very first tool I recommend is Git. I have used it and I have tried to train people on it, and it's so easy to learn. I mean, of course, there are some tricks within it, and you’ll get it while you just go on the higher levels with it. But even at the basics with it, you just have to have Git, because you can use its command line, and also it has a very nice user interface GitHub desktop that you can use, and you can manage your whole repository or your whole code on it. It’s just if you follow the rules correctly like you don’t just merge anything into any of the branches, you can maintain such a nice amount of code consistency across everything. 

And another very nice tool is Jira, and Trello is also quite popular these days. Jira can be linked with Git and automate our stories and our code in that way so that every story has a code linked to it, so as you move the Jira the code moves forward. That was a very nice thing to keep track of. 

Anatoly: Yeah, we use Trello a lot on our team.

Kate: I love Trello. It’s so nice-looking. And especially when you drag the card to “done”. It’s so satisfying. But getting back to our requirements, I just wonder, if there is a common practice to requirements gathering? So how do you guys gather requirements? Maybe you can share some of your experiences?

Anatoly: I don’t think that there’s a standard. But I guess that's exactly what Harshill mentioned: we just try to involve all the parties, including even someone from management to work on achieving the same goal. That’s how it works for many companies.

Harshil: I agree with Anatoly on this one. There are so many domains that are a business domain and then you have to interpret their requirements into the technical domain. That alone creates a lot of branches within the requirements themselves. 

So, let’s say, we wanted to bring in the culture of automation that was their requirement, and then within the team, they had their technical aspects that you need to take care of. So, you know, this is just basic: talk to as many people, gather as much information as you can about the tool, about how the teams are working, and then move on from there. 

Anatoly: Can please share a little bit more information about how the implementation of the tool went? How long have you been planning to spend on it, how long did it take to implement it? Maybe, some funny stories around that?

Harshil: There are so many stories, but the one thing you have to know is that: when you say the day you’ll implement it, it never happens. The date gets pushed because things happen and projects get delayed. For the implementation, I learned that it is not easy to motivate people to accept new ways of doing something that they have been doing for so many years. So, this is something that you have to keep in mind even before you start a project. You have to take the steps very carefully to motivate those people that you know. There will come a time when you have to change this, so you can start preparing for this from now on. For example, for the first team that implemented the whole automation flow, I had to train people on Git. I gave so much training on Git. My condition was “even if at 2 am you wake me up from sleep and you'll ask me to train you on it, I’ll just start to speak and train you on it. It was so good and tiring. 

It took around a year and a half to get from requirements to build the tool and integration phase. 

Anatoly: So true. I mean you usually even if you try to estimate very carefully, you’re still over those estimates. For me it’s just either requirements change while you’re doing the projects or something else is changing. Or you were just wrong with your estimations. It happens that it just takes more time. 

Harshil: The worst thing is that if the person who is responsible for all these leaves like the DevOps expert is like “oh, I’m resigning, I have another good opportunity”.  And you like “What”?

Kate: I think that this is like the risk section when you have to manage all these risks, yes? And also consider all these potential risks when planning something: your roadmap and project. 

Anatoly: Yeah, but the key people usually don’t leave, and this actually kind of a tricky situation when the main expert is living. So, you’ve done your job, what’s next? Let's make it the main topic of the discussion: how to make people use your product? Especially, when it’s an internal product. What did you do?

Harshil: Well, this is something I wish we could have done to make our implementation phase easier. So, as I said, we had five different teams, and what we did, we tried to build the whole system and then we went to the team and we were like, okay, now learn these four tools and implement them and try to change processes. Try to adapt to our automated process. And it's not easy. What we could have done when we started the project was: first we implemented Git, then we implemented TeamCity, the Nolio, then Nexus. So, we could have identified two key people in that team often and would have trained only those two people instead of going ahead and saying: “oh, all these ten people are going to listen to us”. No, it doesn’t happen. You can change one person to change 10 people. It is a different kind of job. So, yes. This is something we could have done and that is for sure going to be the next step when I’m through with my current product that I’m working on. So yes. That is how the implementation went. But it was like a lot of time me running around people’s desks and saying: “oh, you just install this, use these permissions” When you’re in a big company not everything is accessible to you. You need to have a lot of permissions for all those criteria that your system has to fulfill before you get an account to even use that tool. All these formalities come in the way of integration so it is a bumpy road. Building the tool is easy, integrating is hard. 

So, you were running between teams and making people, or forcing people to use the tool. And they were saying “no, no”. Oh, they would say “yes” and when you were leaving the office they were like: “ah, come on”. 

Harshil: See, what will happen is if you want to remain consistent, the first thing you’ve to do is you have to push it on the Git. But the past practice was that they’ll just copy folders from one environment to another and then they will be done with it. So, they will be like “if I can do this, why do I need to learn Git?” 

"To maintain consistency". 

“Yeah, but this guy sits just next to me, and I'll tell him what’s different”.

“No, things don’t work like that”.

“Why doesn’t it work like that. It’s so simple right now. Why do you want to make it complicated?"

So these are the questions that you need to have nice answers to integrate those things.

Kate: So how to stay calm, and just continue explaining. How did you manage all this motivation?

Harshil: That’s where managers come in, right? So the one thing that went wrong was with the person who started all of this. He wanted to implement all of this and hired me to do it. But he left the company midway, as he was promoted to a higher position and moved to the UK and I was in India when all that happened. And the team was like: “okay, we were doing this while he was here because he told us to and now he’s not here anymore, so why do we want to do it?”. So I went to my bosses, and I was like, you know, this is why you hired me and this is why I’m doing this. But I built that thing and nobody’s using it. So please say something to them or give me some kind of authority so that I can push them to do this. And then in their yearly goals, it was written that: “you have to help Harshil to implement this as nicely as possible”. And that is when they were like “okay”. 

So the situation was that I used to run around them and say to give me one hour in their time slot in their calendar. So after the goals were set in their calendar they were like “Harshil, would you like to have a meeting regarding your DevOps thing?”

Anatoly: How could we just avoid this situation and approach the solution to the problem? I mean, the two teams started using the tool without a manager. What do you think, what should be different?

Harshil: The first thing, it has to be a proper authority to motivate people to continue to do their tasks, because that is how it is. If there’s no force behind you, then you won’t just move forward in that direction. So, that is one thing that you have to be sure that you have that kind of managerial support. And the second thing is that not everybody is enthusiastic about technology but in every team, you will find one or two people who want to try new stuff. Identify those people and make them work with you. So, if you have, like in the build phase, contact those technical enthusiasts, they will have a welcomed product, and they would have been like: “now it’s done, now I can use it, and automate my things”. This is something that you have to identify and do.

Kate: How to motivate people to use new tools? How to not be afraid, how to try something new? Maybe you have some experience from your previous projects or current projects? 

Harshil: It’s more of “show, don’t tell”. The moment I showed them how easy things were like “oh, okay”. Before we had lots of presentations where we showed what was going to be automated, using big terms like DevOps and repository management and stuff like that. But the moment that I showed them that with the click of a button, you can deploy your code using TeamCity and Nolio. This is how easy it is for you. You just need to sit and click the button and wait for the screen to turn green, and this is all you have to do. So show, don’t tell. Because people are in their jobs, dealing with their complexities and you just don’t want to bring any other new complexity in their life. You just want to say that it's something easy and you should just try to use it.

Anatoly: So, lessons learned. If we will be summing up, what are the three main lessons that you learned as a product manager, while you were launching this internal product? 

Harshil: The first important lesson is to explore as much as you can. The requirements have to be crystal clear because there were times when we rewrote the code so many times, so I was thinking that “I am doing the same things for six months, and the year and a half past now, what am I doing? I am writing the same code and just changing it”. So that is the one thing. I know that requirements engineering can be boring for some people, but it’s not. It’s fun. If you look at it and define very crystal clear requirements, it will help you. The second is to make it easy and show, don’t tell. Show them how easy the tools are for them. And three is something that can go wrong. It just happens. It happens to everybody and it is going to happen in the future, no matter how much you plan. The lesson that I learned is that it's okay if something goes wrong. 

Kate: I have a question. Could you please recommend any kind of resources: what you read, listen to, and watch regularly?

Harshil: The best thing to do is attend the page on Linkedin, called IIBA (International Institute of Business Analysis). They have a lot of webinars where people come in, share their experience, and listen to their tips, and so on. And another, before I came into all of this, I did a lot of courses and training that helped me a lot. But, you know, talk to people, that is all I would like to say. Talk to your senior managers. People are so intimidated by their senior directors and managers. But when I approached one of them and asked to have a video conference, he agreed. In the video conference, he said that there are 25 people in your team and nobody came and asked me for my advice on how to move forward and  I would love to give some advice. If you want to be a product manager, just talk to your manager. He or she is waiting there to guide you and see you grow. 

Anatoly: That was a fantastic talk. So, thank you for joining us today, and see you guys all in the next episodes.

November 9, 2020Comments are off for this post.

Product Development Backstage: Start New Projects Faster

Custom product development is costly, mostly because developers build everything from scratch. However, there are things that you can automate and thus significantly reduce costs and time for product development. 

In this blog post, we’re going to talk about how to accelerate your product time-to-market with the help of our development framework that automates crucial but repetitive tasks.

1. Authentication and Authorization

Authentication has become an integral part of most mobile and web app architectures. Likely, your app is no exception. Knowing a user's identity allows any application or system to keep these data safe and provide the same personalized experience across all of the user's devices.

The authentication process is what ensures users repeat access to their accounts while preventing any unauthenticated users from gaining access.

We all know the old-school method of registering a user with their basic info (email, password, phone number, etc.).

The process is simple: users input their credentials on the website or app login form. That information is then sent to the authentication server. Then we match the email and password with the previously stored data. If they match, we give them access. If a match isn’t found, users will be asked to re-enter their credentials and try again.

According to Forrester Research, about 11% of people worldwide leave websites if the registration process is too complicated. 

Why You Need Both Authentication and Authorization?

As we all know, registering for a new account is time-consuming and can bother users. Having the option for authorization via social networks allows users to avoid the tedious registration process.  

Of course, you might think that it's not rocket science, and from a technical perspective, all these tasks are routine. It’s hard for us to disagree. However, when developing all this from scratch for your system, you risk spending way more costs and time. 

To save our clients money and time, we created a framework. We call it CXAuth. CXAuth allows deploying secure authentication and authorization modules in the client's system within an hour. This framework is flexible and allows us to automate this process. CXAuth aims to accelerate the project's start. It provides backend services and ready-made solutions to authenticate users to your app. 

In brief, this solution is suitable for:

  • complex systems, where there are several organizations and roles, with each organization has additional settings for each user;
  • more simplified systems. In this case, there is one admin and all the rest are users.

2. User Behavior Analysis 

The process of analyzing your product performance allows us to track how users interact with your app. As a result, it improves user engagement and the product itself.

Related Article: How to increase user engagement: a three-step structure

Our logging framework is based on Logstash, Kibana, and Elasticsearch. It helps you to gain insight into the performance characteristics of your mobile and web apps.

Let’s take a closer look at these concepts and the benefits of using this framework:

Elasticsearch - a search and analytics engine. 

Logstash - a plugin-based data collection and processing engine. 

Kibana - allows users to visualize data with charts and graphs in Elasticsearch.

The value of this framework for digital product development is in the ability to track both technical data and the level of business logic. It helps you to understand how to improve the app performance and fix any issues.  

3. Real-Time Data Synchronization

When you build cross-platform apps, all of your clients share one database set in real-time. They also automatically receive updates with the newest data. It is called data synchronization. Data synchronization is the process of maintaining consistency and accuracy between discrete data sets. Any change that happens to a particular data set is reflected in the other data sets in near real-time.

You should have a way of synchronizing data between databases in real-time. For example, when data is changed in one place, it should be synchronized with another database. Changes need to be detected and automatically synchronized with another database. This process should be fully automated. 

We have developed a set of algorithms and tested them. This set allows us to:

  • Store and sync data with our cloud database.
  • Remain all the data available even when your app goes offline.
  • Sync the data once the device is back online

In addition, data synchronization results in cost-efficiency, high performance, data security, data consistency, and accuracy for an organization.

4. Media Processing

Do you need to have your website or app users upload media to your server? Since you’re not the owner of the incoming files, you can’t guarantee these files to be uploaded in the right JPG and PNG format.
You may ask users to transform the media files. To do that, users need to resize, align, clip, crop, scale, or otherwise fit the image to a particular dimension. Not the best approach in terms of user experience process, right?

A good user experience is when the user uploads the image, and the system automatically converts it without sacrificing the page performance and image quality.

The structure of our framework makes it possible to transform images and videos automatically, without bothering users to convert these files to match your platform standards. If you want to collect any media files, your users add the files, and that’s it. The framework does the rest of the magic.

Related Article: CX vs UX: The complete comparison

What Are the Benefits of Product Development Framework?

In a nutshell, with the help of our product development framework, you save costs and time. It covers a large portion of the services that software developers would normally build themselves for several weeks, whereas they would better focus on the app experience itself. The services provided by this framework are hosted in the cloud and scale with little to no effort on the part of our software developers. Also, this framework allows you to:

  • Sync real-time data in the app. 
  • Provide any social network login with a few lines of code. 
  • Track and measure each user's insights for all the devices - web, Android, and iOS. 
  • Automatically optimize media files so that they load faster on the web and mobile devices. 

In Conclusion 

The core principle of a framework: not having to reinvent the wheel. Our goal is to get rid of low value-added tasks and focus on the business needs of our client. 

For example, the developer won’t need to spend up to three days and create an authentication form. The time saved we dedicate to more valuable tasks. As a result, you will receive a high-quality code and a better app experience.

If you're looking for a reliable team to build your product, we’re here to help. Share details of your project, and we’ll contact you asap

Footer’s logo
    We usually respond within 24 hours.
cxdojo.com Facebook
cxdojo.com Twitter
cxdojo.com Dribbble
cxdojo.com LinkedIn

541 Jefferson Ave. Ste. 100
Redwood City, CA, USA 94063

4a bakulina st. Ste. 48
Kharkiv, Ukraine 61000

4a bakulina st. Ste. 48
Kharkiv, Ukraine 61000