The Underlying Methodologies for Product Management

A PM’s toolbox should contain a fair amount of creative, critical, and strategic thinking, growth mindset, technical knowledge, research skills, and data analysis mastery. 

You also need an underlying methodology that spans across your organization and helps you tame the wild beast called product. Because a product team is not an island. You collaborate across departments and get actively involved in development, design, marketing, sales, customer success, growth – you name it. 

Put that all together and you’ll get a solid ground for efficient planning and strategizing. 

Let’s take a look at the methodologies and frameworks that can help you with this stage – if you’re just starting out with a SaaS business or a startup, or if your company wants to pivot to a different way of working. 

These are mostly software development and design frameworks, but we’re in the business of making digital products, after all. And we need to build, ship, and deliver them to our customers while keeping the customer-centric approach.

Here are some ways you can do it.

The Lean methodology was first explained by Mary and Tom Poppendieck in their book Lean Software Development from 2003. They describe the traditional tools and principles of lean production in relation to software development.

Lean development is not a methodology for engineers only, as it may seem at first. It is a set of principles used by a whole organization to improve the development process, build better products, and increase the chance for greater success in the market.

The seven key principles of Lean software development are: 

1. Eliminate waste: Remove anything that doesn’t bring value to the customer

2. Amplify learning: Accumulate knowledge after each iteration and share it with the team

3. Decide as late as possible: Don’t rush with highly impactful decisions, especially irreversible ones

4. Deliver as fast as possible: The faster you present the product/feature to users, the faster you’ll get their feedback and be able to iterate

5. Empower the team: Ensure everyone on your team understands their own contribution to product and business success 

6. Build integrity in: Don’t leave quality assurance for testing and production phase, solve as soon as a problem appears and eliminate the causes in advance

7. See the whole: Keep the big picture of product strategy in mind, but break down the problems into smaller tasks and issues that are easier to solve

In other words, Lean methodology helps you focus development on value, flow, and people. Its essence lies in three elements – build, measure, and learn.

Whether you implement Lean to product management or you run a Lean startup (which is, thanks to the popular book The Lean Startup by Eric Ries, one of the most frequently used applications of Lean), you’ll create a workflow around building new products/features as tests, experiments, or launches, measuring their impact and user adoption, learning from mistakes and iterating for improvement. 

Back in 2001, seventeen software developers met to discuss some of the problems associated with the product development processes at the time; where excessive planning and documentation contributed to products that were out-of-touch with users. 

They sat down and wrote the Agile Manifesto:

We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:

• >> Individuals and interactions over processes and tools

• >> Working software over comprehensive documentation

• >> Customer collaboration over contract negotiation

• >> Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

There are 12 Principles behind the Agile Manifesto that emphasize the focus on customer satisfaction, sustainable development, self-organization, frequent delivery, and continuous attention to technical excellence and good design.

Today, the Agile methodology is quite popular among product teams, but it can easily be used without a deep understanding of how it works and what it represents. 

As Allen Holub, a well-renowned software architect and consultant focusing on organizational agility, explains in his article on getting started with Agility:

“The word agile means nimble, flexible, adaptable, quick. If you aren’t all of those things, you’re not agile, whether or not you’re using some “Agile” technique. Agile is a frame of mind and a culture, not a process. (...) Agility requires an entire system to support it. The pieces that comprise an Agile system are intertwined. Change anything, and everything has to change, from org structure to company culture to the mechanics of how you build and deploy your software.”

– Allen Holub, consultant, teacher, and speaker 

Using Agile as an underlying methodology for product management and your organization as a whole will help you remove some of the existing silos between research, design, development, and other teams, and increase collaboration between engineers and product managers.

Scrum is one of the most popular Agile implementation frameworks. It is a “time-constrained” product development framework that consists of sprints as pre-set periods of working cycles (typically between one and four weeks). 

Each sprint should have its own goal set collaboratively by the product manager/owner and everyone involved in the delivery. The time-framed approach will enable you to focus on clearly defined sets of features or functionality updates, run experiments, test everything out, and deploy more quickly.

Typically, each team member will use task boards to manage their workflow through a sprint and perform daily stand-ups to report on their daily goals, accomplishments from the previous day, and any obstacles on their way.

As a manager, you’ll be able to track the progress for tasks with sprint burndown charts, a graphic representation of the task completion rate. You’ll also provide feedback, resolve any issues, and ensure that the acceptance criteria are met throughout the sprint. 

The Scrum methodology includes detailed user stories for each of the items the team is working on. That’s why having measurable goals and a clear underlying purpose for each of the items in the backlog is of the utmost importance. This will also help you implement the Product-Led Growth strategy more easily.

Kanban is a scheduling system for lean manufacturing, originally developed by Taiichi Ohno, an industrial engineer at Toyota, to improve Toyota’s manufacturing efficiency. 

Over the years, it has been successfully adopted by software development teams as an Agile implementation framework and popularized by project management tools like Trello, Asana, Jira, Kanbanize, Teamhood, and others. 

Literally translated as “signboard”, Kanban is a method for a clear, sign-based scheduling system that conveys information between processes, and enables just-in-time delivery by maintaining the production at an optimal level. 

In its simplest form, the Kanban board shows “to do”, “in progress”, and “done” items or tasks. Depending on your team’s workflow, you can adjust the board with “backlog”, “requested”, “on hold”, “ready for a review”, “approved”, “deployed”, or other columns. 

An effective application of the Kanban methodology will help you to fine-tune the development process, develop only what’s needed, and keep track of the tasks in each stage. 

Opposite to Scrum, which is a “time-constrained” framework, Kanban is a “capacity constrained” approach. Here’s an example of how a simple Kanban board could look like.

You’ve probably come across discussions around Agile vs. Waterfall, or Scrum vs. Waterfall. Let’s see how these methodologies are different. 

While Agile and Scrum are based on many iterative tests and experiments on the go, the Waterfall methodology focuses on taking the time to build the final product and then move into a maintenance mode. In other words, it’s based on the “measure twice, cut once” approach. 

Here’s a visual representation of this distinction, inspired by the explanation from Takeshi Yoshida.

And here is the overview of the Waterfall product development stages.

The Waterfall model requires investing a lot of resources upfront and spending a huge portion of time on product discovery, product positioning, finding a product-market fit, and creating a go-to-market strategy before launching.

The shortest definition of Design Thinking, given by Bill Burnett, Executive Director of the Design Program at Stanford, would be this:

Design Thinking is a method, not magic.

In a broader perspective, we can define Design Thinking as a set of principles that use human-centered design to understand user needs, validate the ideas through prototype testing, and iterate accordingly. 

This framework can be used as an underlying methodology for overall product management to set the unified process and address various challenges in the product lifecycle.

Experts from IDEO, known to be among the best practitioners of Design Thinking, explain the essence of this method:

“When done right, Design Thinking will help you understand the mindsets and needs of the people you're creating for, surface opportunities based on these needs, and lead you to innovative new solutions starting with quick, low-fidelity experiments that provide learning and gradually increase in fidelity.”

There are five iterative phases of a Design Thinking process:

Keep in mind that this is not a linear process, so you’ll be going back and forth through the phases. And each of the phases will complement the product development process. 

You will empathize with customers through the research and define the problem by discovering their needs, pain points, challenges, questions, and difficulties they face. Then, ideate solutions through collaborative sessions with your team and reflect on possible outcomes. Next, prototype together with designers and engineers for MVPs and beta versions, and test your new products/features through usability testing, user feedback, team reviews, and revisions.

We could also add the sixth phase – Implement – to execute upon the successful solutions and implement them into your products, projects, and overall businesses. 

And, don’t forget to keep users at the center of everything you do. You can use Microsurveys to continuously collect user feedback on new features and product updates.

Jobs to Be Done (JTBD) is a customer-centric theory of understanding what motivates customers to invest in a product or service. A simple JTBD outline from a customer’s perspective is as follows: 

When [situation], I want to [motivation], so that [desired outcome].

The Jobs to be Done framework was founded by Clayton M. Christensen, one of the most influential business thinkers. He explained how the most successful businesses in the world organize themselves around the jobs their customers want to do.

Customers typically have multiple Jobs to be Done, depending on their role, interest, or need. The key is to build a product that will drive Product-Led Growth, address customer needs, and actually improve their life.

Alan Klement, author of the book When Coffee and Kale Compete, defines it like this: 

“A Job to be Done is the process a consumer goes through whenever she aims to transform her existing life-situation into a preferred one, but cannot because there are constraints that stop her.”

– Alan Klement, author of When Coffee and Kale Compete

In the product management sphere, the benefits of Jobs to be Done include focusing on customer needs, building motivation-led products that help users get their job done as efficiently and streamlined as possible, and avoiding inaccurate user segmentation by pinpointing research.

That way, you can tailor messaging to help people overcome anxieties and inertia. Applying JTBD to onboarding flows will enable you to build user journeys that revolve around the customer jobs rather than the product itself.