Agile methodologies and frameworks

Here are a few Agile frameworks and strategic approaches that our product managers regularly use in product development cycles.

Lean Canvas

Lean Canvas was designed to help startups analyze the strengths and weaknesses of their business model. It was developed by Ash Maurya as a variation of the Business Model Canvas (originally created by Alexander Osterwalder).

Technically speaking, Lean Canvas is a one-page document that is divided into nine boxes. Each segment challenges you to identify areas of risk and opportunity, address customer pain points, and create an actionable plan for launching and growing the business. They have the following headings and descriptions:

1. Customer Segments – list your target customers and users.
   • Early adopters – list the characteristics of your ideal customers.
2. Problem – list your customer’s top 3 problems.
   • Existing alternatives – list how these problems are solved today
3. Revenue Streams – list sources of revenue.
4. Solution – outline a possible solution for each problem.
5. Unique Value Proposition – single, clear compelling message that turns an unaware visitor into an interested prospect.
   • High-level concept – describe your idea in simple terms. You can even list an X for Y analogy (e.g. YouTube = Flickr for videos).
6. Channels – list your path to customers.
7. Key Metrics – list the key numbers that tell you how your business is doing.
8. Cost Structure – list your fixed and variable costs.
9. Unfair Advantage – something that cannot be easily copied or bought.

Lean Canvas isn’t just a static sheet with all of your business model’s information. It’s a living document that gets updated regularly by stakeholders, according to customer feedback. We recommend filling in those boxes in the order they are listed above – it’s smoother and, in our experience, less time-consuming.

Our product managers typically leverage this framework when we are refining an idea for a new product. It helps us visualize the proposed business model and think about how we can solve a real problem – not just create features for the sake of features.

Here’s a quick tutorial on how to fill it in, using Uber as a product example:

Feature-Driven Development

Feature-driven development (FDD) is a key Agile concept and a must-know for product managers already using other agile methods: Lean Startup, Pair Programming, Continuous Delivery, etc. Over the years, it’s become more commonplace within product management in SaaS.

The framework is designed to streamline software development by breaking the process down into small, manageable, impactful, steps. FDD facilitates continuous delivery and emphasizes the importance of getting customer feedback early and often. The development team works on releasing working features in a series of short iterations, instead of bundling them together for a major release.

Feature-driven development consists of five main processes, namely:

1. Develop an overall model. Consider all the project requirements and look at the bigger picture: What should your new product do? How will the system work, and how will different parts of it be connected? This architecture will act as your blueprint for subsequent steps in the development process.
2. Build a feature list. Identify and prioritize a list of features to be developed with input from stakeholders (e.g. marketers, designers, c-suite execs, and even customers).
3. Plan by feature. Let’s say you’re building a healthcare system and one of the features on your list is ‘appointment scheduling.’ To improve efficiency, this epic should be broken down into a series of smaller tasks e.g. appointment modification, notification setup, etc.
4. Design by feature. Here the dev team will create a detailed UI and UX for each feature, perhaps even a prototype for a logo design.
5. Build by feature. Once that design is approved by the product team/stakeholders, the feature will be built and implemented along with others in the sprint scope. And the cycle repeats.

FDD is great because it supports rapid development (a must in this competitive landscape) and keeps the product team focused on the value they can bring to customers. Features are properly planned, designed, tested, and validated, ensuring development resources aren’t wasted.

Minimum Viable Product

Many startups fail because they spend months – even years – trying to build a ‘perfect’ product, instead of actually listening to their customers. But in new product development, slow and steady doesn’t win the race – adaptable, fast-learning teams do.

And that’s where the MVP comes in. The minimum viable product, or MVP, is about creating a basic version of your product idea, sharing it with your target audience, gathering customer feedback, and iterating on your idea. Pioneered by Eric Ries, it’s a fundamental concept within his Lean Startup methodology, and is based on the principles of Lean software development.

An MVP includes only the core features and functionality necessary to solve a customer problem or deliver value to the user. Instead of chasing perfection, teams work on reaching a product-market fit faster than competitors and improving the user experience at every step. Growing a startup after an MVP arguably is less challenging too, since it’s easier to make improvements when you know what your customers like and dislike.

To get started, we recommend watching this video on the six steps to building an MVP:

Customer Development

Like the MVP, customer development is more of a strategic approach than a framework – but it’s still a concept that every product manager (particularly in B2B SaaS) should familiarize themselves with.

Customer development, or CustDev, involves engaging with customers early and often to gain insights into their pain points, needs, preferences, and behaviors. The process has four key steps: customer discovery, customer validation, customer creation, and company building. However, our PDMs consider one of the first steps in the process – customer interviews, part of discovery – to be the most important.

At Railsware, we conduct customer interviews for a variety of reasons: to shape the feature or product vision, validate a prototype or MVP, or improve the user experience of an existing product. The feedback we receive during these interviews helps us make unbiased decisions about product strategy. And it’s all about getting closer to a product-market fit.

But the integrity of that information often relies on how those interviews are conducted. Here are some of our top tips:

• Preparation is key. Do plenty of research in advance. Build hypotheses to validate assumptions you have about your new product, target audience, company, etc. And choose your participants carefully – select potential paying users, not just curious people.
• Ask open-ended questions. Don’t ask the interviewee to tell you if X approach is a good idea, or if would they use X feature, and so on. Instead, ask how they feel about X, or when was the last time they used it. Let your customers tell you what they really think.
• Practice empathy. Try to make the interviewee comfortable right off the bat – explain the purpose of the call and how to answer questions. Keep the atmosphere light and the conversation flowing, but listen more than you speak.
• Record the interview. Chances are your interview will take place online. We recommend recording it to make sure you don’t paraphrase your customers’ answers. Their exact wording can provide clues on what to improve.

For a step-by-step guide on how to conduct customer interviews the right way, read our customer development handbook.

Decision-Making Frameworks

Our most trusted product frameworks for complex, multi-context decision-making.

BRIDGeS

After having experimented with various decision-making and discovery frameworks over the years – and not getting the results we wanted – our team developed BRIDGeS: a framework inspired by Pivotal Lab’s Inception. BRIDGeS allows you to deeply analyze the problem, develop multiple solutions, and reach a conclusive decision. It’s suitable for physical or online meetings – see our FigJam template for running virtual sessions.

The first step is problem description, which involves identifying your subject (can be user, tactic, strategy, role – anyone who benefits from the solution) and decomposing your problem using different descriptors. Multiple stakeholders should be involved in the session (e.g. a product manager, engineers, designers, marketers, or analytics engineers  – between 3-8 total). BRIDGeS stands for Benefits, Risks, Issues, Domain Knowledge, Goals, and Solutions. So, start by describing your problem using each one.

• Benefits are the elements of value your subject will derive from the solution.
• Issues are the existing problems of the subject.
• Risks denote potential issues the subject might face in the future.
• Domain Knowledge is any information about subjects or the context in general that is useful to keep in mind.
• Goals are what the subject hopes to get from the future solution.

The next step is prioritization. At this point, you are still in what we call the Problem Space. We use the MoSCoW method (hint: we explain this in detail further in the article) to mark all subject descriptors with a level of priority: Must, Should, Could, and Won’t.

Now we move into the Solution Space. This is the point where you brainstorm solution variations that satisfy the needs stated in the Problem Space. It should be easier to generate solutions by analyzing your described and prioritized problem from the top down. And there you have it: one or more actionable solutions that offer a conclusive decision.

However, if you are dealing with a particularly complex issue, you may need to move on to step 4: Solution Breakdown. Here, you can decompose a high-level solution by describing it through epics and nested tasks, and dive as deep into the context as needed. You can also use that list of epics and tasks to build a product roadmap.

Logic Tree Framework

The Logic Tree framework offers a systemic approach to complex decision-making. It’s been around since the 1960s when it was initially described as a regression tool to identify what triggered a failure. Nowadays it’s used in both ordinary decision-making and retrospective analysis contexts.

Like BRIDGeS, Logic Tree allows you to dive deep into the problem context and break down your issue into smaller components. Its visual aspect (as the name suggests, a tree-like structure) makes evaluating the various sub–problems and solutions less painful. You can also use a virtual board (Miro, FigJam) and colored cards to map the process.

Here’s how to utilize the framework:

• Clearly identify and state your problem. This will form the basis for all potential sub-problems and solutions, so make sure you choose the right one.
• Consider all possible solutions to that problem, even if they aren’t ideal. The main thing is to be creative in how you approach the issue.
• Carefully evaluate each option, or ‘branch’, and jot down their benefits, drawbacks, risks, and opportunities – anything relevant that comes to mind.
• Compare those options and explore each in more detail if need be.

It’s worth pointing out that the Logic Tree framework won’t provide you with a definitive solution to your problem. It’s more of a tool for investigating the entire context surrounding an issue, so you can make a well-informed decision based on all of the information you’ve teased out.

Interested in other alternatives for your team? Check out the rest of our top product frameworks for multi-context decision-making.

Prioritization Frameworks

Here are two of the most effective frameworks for product planning, managing workloads and organizing project priorities.

MoSCoW Framework

MoSCoW is one of the most popular prioritization frameworks out there, and rightly so. It’s simple, practical, easy to remember, and can be used in a variety of contexts. MoSCoW was developed in the 90s by Dai Clegg, who worked for Oracle at the time. Our product managers regularly use it for tasks like sprint planning, backlog refinement, and product improvements prioritization.

Each capital letter in MoSCoW denotes a level of priority, from high to low. The letters stand for Must-have, Should-have, Could-have, and Won’t-have.

To demonstrate how each can be applied, let’s say you are developing an e-commerce MVP and need to prioritize product requirements. You have a list of features and functionalities (e.g. ‘create an account,’ ‘product reviews,’ ‘payment processing system’) but need to decide which ones to implement first.

• Must-haves are top priority requirements. The app must allow customers to browse a catalog of products and make purchases online.
• Should-haves are requirements of secondary priority. The app should allow customers to create an account and save their shipping and payment information. 
• Could-haves are desirable additions. It would be nice if the app could allow customers to leave product reviews. 
• Won’t-haves (this time) are non-essential features that don’t need to be included in the initial release. For now, the app won’t recommend new products to customers based on their past purchases.

Don’t fall into the trap of tagging every feature or task as a ‘must.’ MoSCoW only works when the team is honest and realistic about the importance of product requirements. For advice on how to apply the framework to your product backlog, watch this video:

RICE Scoring Model

RICE is another solid prioritization framework to have in your pocket. It’s the invention of Sean McBride, former Product Manager at Intercom, who wanted to take the pain out of product roadmap prioritization and help PDMs make better data-driven decisions.

RICE is an acronym for Reach, Impact, Confidence, and Effort – four key factors by which each feature, hypothesis, or user story can be measured.

To show how RICE works in practice, let’s say you have developed a social media app and you’re deciding on which product improvements to implement first. One of the options is a translation tool that will automatically translate posts and comments into different languages, making the platform more accessible for non-English speaking users.

We can assess the feature’s priority level through the following factors:

Reach refers to the number of people who will use the feature within a given time period. You might estimate that half of your current monthly active user base would use the translation feature each quarter. So reach is 10K customers per quarter.

Impact quantifies the amount of value that a new feature will add to your product. To help with this, Intercom developed a ‘multiple choice scale: 3 for “massive impact”, 2 for “high”, 1 for “medium”, 0.5 for “low”, and 0.25 for “minimal.”’ Let’s say you decide that the translation feature has an impact score of 1, based on the results of your recent hypothesis tests.

Confidence. When you don’t have all the data to back up your enthusiasm about a feature, you can give it a confidence score. Measure this in percentages: 20% is a Moonshot, 50% is Low Confidence, 80% is Medium Confidence, and 100% signifies High Confidence.

Effort. This is an estimate of the amount of time and resources it will take to deliver the new feature. Intercom recommends doing this by calculating ‘person-months’ – how many members of the team would be dedicated to this feature every month until completion.

So, the formula for determining priority is (Reach x Impact x Confidence) / Effort = RICE score.

At Railsware, we don’t use RICE as widely as we use MoSCoW. Frankly, the framework is quite time-intensive and decidedly more complex. But sometimes our product managers find it helpful for measuring a feature/project’s impact on revenue.

Product metrics frameworks

Two reliable frameworks for accurately measuring product performance.

AARRR Pirate Metrics framework

The AARRR metrics framework is modeled on the conversion or marketing funnel. It was first developed by Dave McClure, a venture capitalist and founder of 500 Startups. For easier pronounceability, he dubbed the framework ‘Pirate Metrics.’

The acronym stands for Acquisition, Activation, Retention, Revenue, and Referral. Each metric corresponds to a stage in the customer journey. By examining changes (or lack thereof) in user behavior at each stage, PDMs can pinpoint areas of drop-off and measure user engagement or dissatisfaction. Armed with that data, they are better equipped to make targeted product improvements. We typically build our main product dashboards around this framework, since it offers a broad and balanced overview of product success.

Let’s take a look at how AARRR metrics could be applied to one of our products, Mailtrap – an email delivery platform designed for developers.

• Acquisition refers to how many people we attracted to the platform via channels like social media, SEO, or pay-per-click (PPC). It can be measured by click-through rates, service requests, and site engagement.
• Activation is the number of people who set up a Mailtrap account and start using the product features i.e. they have either conducted email testing or sent an email using our SMTP/API.
• Retention is the number of users who stuck around after signing up. At Mailtrap, we classify an active user as someone who tests or sends emails 1/3/7 days after the first activation.
• Revenue is defined by our monthly recurring revenue (MRR) or annual recurring revenue (ARR).
• Referral is how many users recommend our product to others. This can be measured via customer support ratings or online reviews. (Note: we don’t measure referral rates for most of our products, including Mailtrap).

Sometimes, our product managers replace the first ‘A’ in the framework – Acquisition – with Awareness. This is the number of people who were exposed to our marketing campaigns and other outreach efforts. Tracking Awareness gives us an insight into the bigger picture: how many people who encounter the brand end up engaging with it in some way?

Objectives and Key Results (OKR) framework

OKR wasn’t immediately popular when it was first introduced by Intel’s Andrew Grove in the 1970s. In fact, it only saw widespread adoption when John Doerr introduced it to Google in the late 90s. But ever since then, it’s been the goal-setting and metrics framework of choice for countless organizations.

Objectives and key results, or OKRs, help product managers set goals that align with the company’s vision and product strategy. Mainly, it keeps teams focussed on the outcome rather than the tasks needed to complete a goal. OKR is typically implemented in quarterly cycles (checkups every 3 months).

To leverage the framework, start by choosing a product objective that’s both ambitious and measurable. Then set 3-5 key results that will help you track progress toward that objective.

Here’s an example.

Objective: We want to increase user engagement twofold over the next quarter.

Key results:

• Increase monthly active users by 20%
• Increase the number of features used by each user by 10%
• Increase the average session duration by 15%

Key results should be specific, time-bound (end-of-quarter deadline), and supported by an action plan. For example, to increase monthly active users, your product team might make improvements to the onboarding experience and/or experiment with new UX copy. To stay on track, you can organize those tasks in a product roadmap.

Avoid setting objectives that are too simple, such as ‘Increase sales.’ Be as specific as possible, because if you reach your objective too quickly, that’s a sign it wasn’t ambitious enough.

Wrapping up

Product management is multi-faceted. There is no one-size-fits-all approach, and every organization has its own processes and preferred ways of solving problems, making decisions, prioritizing workloads, and tracking product success. However, we consider the above product frameworks and methodologies to be some of the most useful in the industry. They are dynamic, practical, and easy to apply. At Railsware, most of these frameworks have been pivotal in helping us grow and succeed as a product studio. If you’re interested in learning more about how we leverage them, check out our product development services.