Agile product development: Framework & best practices

Traditional product development plans everything upfront and follows a strict, sequential process with heavy documentation, known as the software development life cycle or Waterfall. In contrast, Agile emphasizes flexibility, collaboration, and rapid iteration throughout development.

Agile builds in small increments, ships quickly, learns from real feedback, and adjusts direction iteratively. Originating from the 2001 Agile Manifesto by software developers, Agile’s 12 principles promote collaboration, flexibility, customer focus, and continuous improvement. These principles now guide Agile methodologies beyond software.

For example, Linear, an issue tracking tool, ships weekly updates with small improvements based on user feedback, continuously discovering and building what users need rather than following a fixed plan.

Core agile principles

• Ship working product frequently (weeks, not months) through an iterative development process

• Welcome changing requirements based on learning, even late in development

• Collaborate with users throughout development

• Build features incrementally using iterative development, rather than all at once

• Reflect and adapt your process regularly

• Measure progress primarily through working versions of the final product

For research teams, this means your work changes. Instead of big studies informing 18-month roadmaps, you’re doing continuous research informing next week’s decisions. Agile focuses on delivering business value by aligning product features with real user needs and feedback. Agile also prioritizes customer satisfaction through early and continuous delivery of valuable software, welcomes changing requirements to harness change for the customer's competitive advantage, and measures progress primarily through working versions of the final product.

The agile framework basics

Most agile teams follow some variant of Scrum or Kanban, which are key frameworks within agile methodologies and the agile product development methodology. Agile methodologies include frameworks such as Scrum and Kanban, which help teams manage their workflows effectively.

An agile process and agile practices focus on flexibility, collaboration, and iterative delivery, enabling teams to adapt quickly to changing requirements and user feedback. These approaches are grounded in agile development principles, which emphasize customer needs, continuous delivery, quality, and adaptability.

Understanding the basic structure helps you figure out where research fits.

Sprints and iterations

Work happens in short cycles called sprints, typically 1-4 weeks. Two weeks is most common. Agile product development uses an iterative approach, breaking work into multiple iterations (sprints) to deliver working software frequently. This enables teams to adapt quickly, gather feedback, and make incremental improvements throughout the process.

Each sprint follows the same pattern:

• Planning: Team decides what to build this sprint

• Development: Team builds it

• Review: Team shows what they built and gets feedback

• Retrospective: Team discusses what to improve about their process

In Agile, teams work in sprints to develop and test products continuously, whereas Waterfall requires completing one phase before moving to the next. Then you start the next sprint. Notion runs two-week sprints. Week one focuses on building. Week two includes refinement, testing, and preparing for the next sprint. By delivering working software frequently through these iterations, they ship updates every two weeks, learning from user response before planning the next sprint.

Backlogs and prioritization

Instead of long-term roadmaps, agile teams maintain backlogs—prioritized lists of things that could be built.

• The product backlog contains all potential features, improvements, and fixes. User stories are used to capture customer requirements and guide prioritization, ensuring the backlog reflects what matters most to users. It’s constantly reprioritized based on new information.

• The sprint backlog is what you commit to building this sprint.

Priorities change. A user insight from this week’s research might bump something to the top of the backlog. Something that seemed important last month might drop off entirely.

Figma’s backlog constantly shifts based on user feedback, analytics, and research findings. Understanding customer needs is crucial in Agile product management to ensure that product iterations meet user expectations. Features that seemed critical three months ago sometimes get deprioritized when research reveals users have more urgent needs.

Roles in agile teams

• Product owner: Decides what to build and prioritizes the backlog. This person represents user needs and business goals. Product managers often fill this role, gathering data, driving product discovery, and aligning team efforts to deliver customer-centric solutions.

• Development team: Engineers, designers, and other people building the product. In agile, they’re cross-functional teams and self-organizing teams, empowered to manage tasks, make decisions, and drive innovation. This structure is key to Agile, as self-organizing teams are believed to generate the most value in Agile product management. Assigning clear roles within the Agile product team helps streamline processes and improve collaboration. Agile product teams are collaborative and flexible, adapting quickly to changing requirements.

• Scrum master: Facilitates the process, removes blockers, ensures the team can work effectively. Some teams skip this role.

• Researchers: Not officially in the Scrum framework but critical for user-centered agile teams. Research informs what goes in the backlog and validates what gets built.

Agile ceremonies

These regular meetings structure agile work:

• Sprint planning (start of sprint): Team reviews the backlog and commits to sprint goals. Agile ceremonies like Sprint Planning foster collaboration and efficient face-to-face communication, whether in person or via video.

• Daily standup (daily): A quick 15-minute sync where team members share updates and blockers. These standups leverage face-to-face communication for effective collaboration.

• Sprint review (end of sprint): Team demos working product to stakeholders and collects feedback, maintaining alignment and transparency.

• Sprint retrospective (end of sprint): Team reflects on the process to identify improvements.

Spotify adds research-specific ceremonies. They hold weekly research shareouts where researchers present recent findings relevant to upcoming sprints.

Agile vs. Waterfall: Key differences

• Agile Product Development is iterative and incremental, allowing for ongoing changes and improvements.

• It welcomes changing requirements throughout the development process, adapting as needed.

• Agile emphasizes frequent delivery of working software to gather continuous feedback.

• There is continuous user feedback and collaboration between teams and customers.

• Progress is measured primarily through the delivery of working products.

• Agile adapts quickly to change, providing flexibility throughout the project lifecycle.

In contrast, Waterfall Product Development is characterized by:

• A linear, sequential development process.

• Fixed requirements determined upfront, with little room for change.

• Delivery of the product happens only at the end of the project.

• Customer input is mostly limited to the start and end of the process.

• Progress is measured via documentation rather than working products.

• It is difficult to make changes once the process has started.

How research fits into agile development

Traditional research cycles don’t match agile’s speed. You can’t do eight-week research projects when teams ship every two weeks.

Agile research means adapting your methods to deliver insights when teams can act on them. In agile product development, customer feedback, continuous feedback, and customer data play a crucial role in informing decisions, prioritizing features, and supporting iterative improvement. Agile emphasizes customer collaboration throughout the development process, while Waterfall typically involves customer input only at the beginning and end.

Continuous discovery

Instead of big research projects, you’re doing lightweight research continuously. This approach is rooted in agile values and the principle of continuous improvement, where teams iterate and deliver high-quality experiences by regularly incorporating user feedback. Iterating and delivering high-quality experiences is a core practice in Agile product management, allowing for continuous improvement based on feedback.

This means:

• Talking to 3-5 users weekly instead of 30 users quarterly

• Quick prototype tests rather than comprehensive usability studies

• Ongoing analytics monitoring instead of periodic reports

• Rapid surveys rather than extensive questionnaires

Superhuman’s research team talks to users every week. Not formal interviews. Just conversations about how they’re using features, what’s confusing, what they wish existed. These conversations inform the next sprint’s priorities.

The insights are smaller and more focused but they’re timely. Product teams can act on findings immediately rather than waiting months for a research report.

Research in sprint planning

Before each sprint, research should inform what gets prioritized. Effective project management and agile product management are crucial in this process, as they help teams prioritize work, align on goals, and ensure that resources are managed efficiently. Creating a rock-solid product strategy is essential for effective Agile product management, providing a clear direction for the team and supporting iterative improvements.

This might be:

• Recent user feedback highlighting problems

• Analytics showing feature struggles or opportunities

• Quick concept tests validating which direction to take

• Competitive insights revealing gaps

Asana’s sprint planning includes a research briefing. Researchers share key insights from the past two weeks that should influence upcoming work. This might be usability issues to fix, feature requests to consider, or validation results on concepts being discussed.

Testing during sprints

As features get built during sprints, researchers test them before they ship. In agile product development, teams often create a minimum viable product (MVP), a simplified version of the product, to quickly validate ideas and gather feedback for iterative improvement. This approach helps teams respond rapidly to changing customer needs and market conditions.

This doesn’t mean comprehensive testing. It means:

• Testing early prototypes with 3-5 users to catch major issues

• Quick usability checks on working features before release

• Internal dogfooding to spot obvious problems

• Accessibility checks ensuring features work for everyone

Calendly’s researchers test features mid-sprint when there’s still time to adjust. They might spend 2-3 hours testing a new scheduling flow with a few users, identify confusing elements, and engineers fix them before the sprint ends.

Learning from shipped features

After shipping, you’re measuring whether features succeed.

Agile teams track:

• Adoption rate (are users trying it?)

• Usage patterns (how are they using it?)

• Satisfaction (do they like it?)

• Impact on key metrics (does it improve retention, conversion, etc?)

In Agile product development, the primary measure of progress is delivering a working product that meets user needs. Teams measure progress by releasing functional versions and evaluating their real-world usage. Measuring strategy and product success through key performance indicators is also essential to ensure alignment with business goals.

This learning feeds back into the backlog. Features that succeed might get expanded. Features that don’t get revised or removed.

Linear tracks detailed metrics for every shipped feature. They measure adoption in the first week, first month, and ongoing. Features with low adoption trigger research to understand why, was it poorly designed, not valuable, or poorly communicated?

Agile research methods

Traditional research methods don’t disappear in agile. You adapt them to work at sprint speed. Agile product development emphasizes collaboration between cross-functional teams and stakeholders throughout the project. Knowledge sharing and collaboration tools play a crucial role in supporting agile research methods, enabling teams to communicate efficiently, manage workflows, and adapt quickly to changing requirements.

Types of agile research methods

• Lightweight user interviews:
  Instead of hour-long interviews with 20 people, you do 20-30 minute conversations with 5 people. You're not trying to be comprehensive. You're trying to understand enough to make informed decisions.
  Questions are focused:

  • "Walk me through how you use [specific feature]"

  • "What's confusing about [thing we're considering building]?"

  • "Show me your current workflow for [task we want to improve]"
    Miro's researchers conduct 15-minute "feature conversations" with users. They're not exploring broad user needs. They're validating specific questions about features in development.

• Rapid prototype testing:
  Build quick prototypes in Figma or similar tools and test with 3-5 users. You're not looking for comprehensive findings. You're checking if the concept makes sense and catching major usability issues.
  Tests might be 30 minutes. You show the prototype, ask users to complete key tasks, observe struggles, and document issues. No lengthy reports. Just share findings immediately with the team.
  Notion tests early prototypes for every major feature. Their designers create clickable prototypes and researchers test them with a few users. If something's confusing, they redesign before engineers write code.

• Quick surveys:
  Send short surveys (5-10 questions) to specific user segments to validate assumptions quickly.
  You're not trying to be statistically perfect. You're getting directional data fast. 50-100 responses can tell you if you're on the right track.
  Amplitude uses in-product surveys triggered after users interact with specific features. They ask 2-3 questions about the experience while it's fresh. Results come back within hours, not weeks.

• Analytics monitoring:
  Set up dashboards tracking key behaviors so you don't need to run analysis manually every time someone has a question.
  Product teams should be able to check:

  • Feature adoption rates

  • User flows and drop-off points

  • Cohort retention

  • Conversion funnels
    Spotify maintains dozens of dashboards so teams can self-serve basic questions. Researchers spend time on complex analysis, not pulling simple numbers.

• Session replay review:
  Watch recordings of users interacting with your product to understand behavior patterns and identify friction points.
  You're not watching hundreds of sessions. You're sampling 10-20 sessions showing interesting patterns from your analytics.
  Dropbox researchers watch session replays when analytics show unusual behavior. If completion rates drop for a specific flow, they watch sessions of users who abandoned to see what went wrong.

Best practices for agile research

Making research work in agile requires adapting your approach. One of the core principles of agile product development is continuous improvement, teams regularly gather user feedback, iterate on solutions, and refine their products through repeated cycles. Agile product development also encourages teams to reflect regularly on their processes to improve efficiency and effectiveness, ensuring that research and development efforts are always aligned with evolving goals and user needs.

Build research into the rhythm

Don't treat research as separate projects. Make it part of the regular sprint cadence.

• Establish research touchpoints:

  • Weekly user conversations

  • Mid-sprint prototype testing

  • Post-sprint impact assessment

  • Monthly deeper dives on strategic questions

Intercom schedules research activities in recurring slots. Every Tuesday, they test prototypes. Every Thursday, they analyze shipped features. This rhythm means research is continuous, not occasional.

Prioritize ruthlessly

You can't research everything. Focus on the highest-impact questions.

• Ask yourself:

  • Does this decision materially affect user experience?

  • Is the team uncertain enough that research would change their direction?

  • Can we learn from shipping and measuring rather than researching first?

If research wouldn't change the decision or you can learn just as well by shipping, skip it.

Linear's research team says no to most research requests. They focus on big bets where research prevents expensive mistakes and skip research for incremental improvements that can be iterated based on post-launch feedback.

Share insights immediately

Agile teams can't wait for polished reports. Share findings as you learn them.

• Use:

  • Slack messages with key findings and video clips

  • Quick debriefs after research sessions

  • Shared documents updating in real-time

  • Stand-up mentions of critical insights

Figma's researchers post findings in Slack immediately after sessions. A quick message like "Just tested the new sharing flow with 4 users, all struggled with the permissions dropdown, video clip here" is enough for designers to start fixing it.

Test with imperfect prototypes

Don't wait for high-fidelity designs. Test rough sketches, wireframes, and early working versions.

• You're learning if the concept works, not whether the visual design is perfect. The less polished your prototype, the more users focus on functionality over aesthetics.

Notion tests with extremely rough prototypes. Sometimes literally sketches on paper or basic Figma shapes. They're validating ideas, not designs.

Create reusable research artifacts

Build templates, participant panels, and research infrastructure making future research faster.

• This includes:

  • Recruitment email templates

  • Discussion guide frameworks

  • Analysis templates

  • Participant databases

Slack maintains templates for common research types. When they need to test navigation, they have a standard discussion guide they adapt rather than starting from scratch each time.

Balance strategic and tactical research

Agile's speed pushes teams toward tactical research, testing what's being built right now. Don't lose strategic research understanding longer-term needs.

• Reserve capacity for bigger questions:

  • Where should the product go next quarter?

  • What user needs aren't we addressing?

  • How is our market evolving?

Amplitude dedicates 30% of research capacity to strategic questions not tied to current sprints. This prevents optimizing short-term details while missing big opportunities.

Common agile research challenges

Teams face predictable issues when adopting agile research. A core principle of agile product development is sustainable development, which emphasizes maintaining a sustainable work pace to avoid burnout and keep motivation high. Agile methodologies encourage setting realistic goals, making incremental progress, and regularly reflecting to ensure long-term productivity.

Research becomes reactive

Without planning, research only responds to immediate questions without questioning if the right things are being built.

Solution: Reserve 20-30% capacity for proactive, exploratory research.

Pinterest dedicates Fridays to strategic research, supporting active sprints Monday through Thursday.

Research timing mismatches sprints

Recruiting and analysis may not fit two-week sprints.

Solution: Stagger research so sprint N informs sprint N+1 or N+2.

Webflow plans research one sprint ahead of development.

Pressure to skip research

Teams may cut research to save time during product development, risking costly rework.

Solution: Track "research ROI" to show time saved by catching issues early.

Loom found research prevents 10x the time spent on rework.

Speed reduces research quality

Small samples and quick studies risk lower rigor.

Solution: Accept directional insights over perfect rigor.

Superhuman uses small samples to identify clear usability problems through research studies, which is increasingly relevant as teams seek to gather and analyze market insights market research continues to evolve in 2025.

Researchers overwhelmed

Supporting multiple teams and strategic work causes burnout.

Solution: Hire more researchers, train teams for basic research, or reduce team load per researcher.

Notion keeps a ratio of one researcher per 2-3 teams for balanced capacity.

Integrating research into common agile frameworks

Agile software development emphasizes iterative planning, rapid feedback, and continuous improvement, contrasting with traditional linear methods like Waterfall. Agile embraces changing requirements, customer collaboration, and frequent delivery, making it ideal for projects with uncertainty.

Scaling Agile with frameworks like SAFe promotes cross-functional collaboration and alignment across teams to enhance productivity.

Scrum integration

Research fits into Scrum ceremonies:

• Sprint planning: Share insights to guide priorities.

• Daily standup: Update on research progress.

• Sprint review: Present validation results.

• Retrospective: Reflect on research process.

Researchers manage a sprint backlog aligned with product sprints.

Kanban integration

Kanban’s continuous flow integrates research by ensuring features move to development only after key research is complete. Testing includes user validation before completion.

Dual-track agile integration

Dual-track agile separates discovery (research/design) from delivery (development), running in parallel. This approach ensures validated features before engineering begins and is highly research-friendly, as used by Spotify.

Continuous delivery and deployment in agile

Continuous delivery and deployment are central to modern agile development, enabling software development teams to deliver value faster, more reliably, and with less risk. In the agile product development process, these practices transform how teams build, test, and release working software, allowing rapid response to changing customer needs and business objectives.

• Continuous delivery keeps software in a deployable state at all times. Automated testing and deployment pipelines validate every code change, so the development team can release updates whenever needed. This supports the agile principle of early and continuous delivery, ensuring valuable software reaches users frequently with short feedback loops.

• Continuous deployment goes further by automatically releasing every validated change to production. Once code passes all tests, it is deployed without manual intervention, reducing bottlenecks and enabling agile teams to deliver features, fixes, and improvements at a steady pace.

Tools for agile research

Having the right tools makes agile research practical. Agile product management tools and collaboration tools are essential for supporting agile research, enabling teams to plan, prioritize, and communicate efficiently in real time. Agile product management tools like Jira and Trello help teams manage sprints, backlogs, and user stories, ensuring that workflows remain organized and adaptable throughout the agile product development process.

Research repositories

• Dovetail or Aurelius organize research findings so teams can search past insights when questions arise.

• In agile, you can't re-research everything. Having searchable past insights prevents duplicating work.

Participant management

• User Interviews or Respondent help recruit research participants quickly, which is essential when you need users for testing on short notice.

• Maintaining your own participant panel also helps. You can email your panel and get participants within 24-48 hours.

Prototype testing

• Maze or Lyssna enable unmoderated testing where users complete tasks with prototypes on their own time. Results come back in hours instead of days.

• This speed matches agile cadence better than scheduling moderated sessions.

Analytics

• Amplitude, Mixpanel, or PostHog track user behavior, letting you measure feature impact quickly after shipping.

• Real-time analytics means you know within days whether a feature succeeds, not months.

Communication

• Slack or similar tools enable sharing insights immediately. Create channels for research updates where you post findings, video clips, and quick summaries.

• Async sharing means insights reach teams when they need them, not just in weekly meetings.

Measuring research effectiveness in agile

Traditional research metrics (number of studies, sample sizes, report pages) don’t capture value in agile. In agile product management, it’s essential to measure progress by tracking working versions of the product and using key performance indicators (KPIs) to evaluate both strategy and product success. Better metrics include:

• Decision velocity: How quickly does research enable teams to make decisions? If research answers questions in time for sprint planning, it’s working.

• Research-informed decisions: What percentage of sprint decisions reference research insights? Track when teams explicitly cite research in their rationale.

• Rework reduction: How often do shipped features need major changes versus minor tweaks? Good research reduces rework by catching problems early.

• Outcome improvement: Do features informed by research perform better (higher adoption, satisfaction, retention) than features built without research?

Linear tracks which features involved user research and compares their success metrics. Features with research validation have 2 times higher adoption rates on average.

Starting agile research in your team

To begin agile research, adopt an agile mindset focused on collaboration, flexibility, customer-centricity, and continuous improvement. Recognize that this may require a cultural shift for teams used to traditional methods.

Steps to start:

1. Join sprint planning to understand upcoming work.

2. Choose 2-3 features where research can reduce uncertainty.

3. Conduct quick studies (5 users, 30 minutes) and share findings promptly.

4. Measure impact, did teams act on insights and avoid issues?

5. Build trust with small wins and expand research gradually.

Start small, prove value, and grow. Calendly’s team began by sharing session replay insights in Slack, leading to full integration of research in sprints.

The honest truth about agile research

Agile research is challenging due to its speed, constant context-switching, and pressure to stay relevant. It requires trading perfect rigor for timely, high-impact insights that directly influence upcoming releases. Successful agile research focuses on strategic moments where research adds value, skipping exhaustive studies in favor of quick validation and learning through shipping. Maintaining technical excellence and sustainable development ensures teams avoid burnout while delivering quality. If you're struggling, start small, prioritize high-impact questions, and build from there.

Ready to act on your research goals?