Extended Impact Mapping: Identifying the real problems that your product should solve.

People are the reasons why we build Products. Products are meant to solve a problem for the people. For example, if we are building a Car-pooling application in Bengaluru, we are trying to solve the problem of traffic jams. The car-pooling app won’t solve that problem but people do. The car-pooling app has to address the constraint that people face in pooling the car. One of the reasons why people may not car pool could be the issue of safety. If car-pooling app can’t address it people don’t car pool and vision can’t be achieved. Extended impact-mapping helps in understanding those constraints to help Product teams in helping the products features to address those constraints.


2 favorite thumb_down thumb_up 1 comment visibility_off  Remove from Watchlist visibility  Add to Watchlist

Outline/structure of the Session

  • Share a case study where Extended Impact map was used and useful
  • Explain how to build extended impact maps.
  • Let participants use extended impact mapping for building impact stories for their own product.
  • Review and provide feedback.
  • Discuss how to use Contribution Quadrant to identify an area for exploring MVP.

Learning Outcome

At the end of the session, participants will learn:

  • What is an Impact Map?
  • What is an extended Impact Map?
  • Why Impact story is more powerful?
  • How to use impact mapping to develop impact stories?
  • How to prioritize product backlog using Contribution Quadrant?

Target Audience

Product Managers, Product Owners, Business Analysts, Product Marketing Managers

schedule Submitted 1 year ago

Comments Subscribe to Comments

comment Comment on this Submission
  • Matteo Taddei
    By Matteo Taddei  ~  1 year ago
    reply Reply

    Hi Satisha,

    can you share with us some slide of talks you gave in the past or a even a video? It will help us seeing your presentation style.

    Thank you!

    • Liked Naveen Kumar Singh

      Naveen Kumar Singh - Anti-patterns of Sprint Planning – skill-based task creation

      45 Mins

      We often see team create tasks for product backlog items during sprint planning but those tasks are skill-based task like coding, testing, documentations etc. Is it a right way to do? What all can go wrong if we keep creating tasks like this?

      • Team may not focus on delivering end-to-end feature and every members are just concern about their respective tasks but what about whole feature?
      • Team members may not be interested in hearing other’s work so Daily Scrum may become boring for team and team may not be interested in each other work.
      • Sprint planning may get completed quickly without going in details. This may lead to poor planning for iteration.
      • Team may not discuss about design and architecture during planning and that will lead to duplicate code to avoid dependencies on each other during execution.

      I will share my learning on how to plan sprint to avoid above issues. 

    • Liked Naveen Kumar Singh

      Naveen Kumar Singh - Specification by Examples - Writing executable specification

      90 Mins

      This is a workshop to build product while practicing impact mapping, feature writing, specification by examples and applying test first approach. Workshop will practices that will help in translating product vision to product increment and living documents. Facilitator will demonstrate how to convert specifications in code by using test first approach.​​ Facilitator will help in crafting product vision, coming up with product features, how to write examples for features and use examples to write production code. Session will demonstrate how to convert specification into product increment, living documents and build test automation.

    • Liked Satisha Venkataramaiah

      Satisha Venkataramaiah - Change Canvas – A technique to create a Shared Need for Organization Agility

      90 Mins

      If someone says we want to adopt Scrum or some other framework, there is always a problem that Scrum can solve for them. Many a time, people at the helm of helping Organizations solve that problem lose the focus on the problem and Scrum becomes their main goal. Change Canvas is a way to help everyone involved in Organization transformation stay focused on solving the underlying problem that Organization thought Scrum could solve. This technique uses 5 HOWs, Change mapping and Contributor Quadrant to build the canvas. This helps in using Scrum as an Organizational transformation framework rather than just a delivery framework. 

      In this 90-minute workshop, Satisha will help you build a Canvas for your problem.


    • Liked Satisha Venkataramaiah

      Satisha Venkataramaiah - leanGears Discovery – A framework for discovering Product Requirements.

      480 Mins

      A Product is not the end goal for users rather it’s a means to do activities in real life to fulfill their needs. A Valuable Product is one that helps the end users do those activities easily and willingly. 

      A Product owner is someone who understands the customers who buy the product, end users who use the product and sponsors who invests in the product and prioritizes the work done by the development team to maximize the value of money and time spent by them(Customers, end users and sponsors). Scrum do not prescribe a specific way of discovering requirements and value as discovery process varies widely based on domain. leanGears Discovery framework attempts to give guidance to Product Owner to discover product requirements and identify value.

      In this workshop, Satisha will give you an existing Problem and help you discover Product requirements to solve that problem using leanGears Discovery framework.