User-Centric Agile Development

Goodbye, INVEST Method Agile teams have long relied on the INVEST Method to craft well-defined user stories. It’s a refinement technique that helps teams write Independent, Negotiable, Valuable, Estimatable, Small, and Testable stories. But I don't think INVEST works well in practice anymore. Today’s teams face complex dependencies, cross-team collaboration, and an emphasis on UX, flow, and systems thinking. It’s time to FOCUS on a new method that addresses modern Agile challenges: Flow-Oriented Outcome-Driven Collaborative & Clear Usability-Centric Sustainable & Sliced INVEST Falls Short In complex systems, many stories are dependent on something. Forcing independent stories may lead to splitting work in ways that don’t align with user workflows. Instead, minimize dependencies and deliver thin, end-to-end slices of value. Overly negotiable stories invite waste and rework. Teams debate what to build after the sprint starts instead of achieving consensus beforehand. Not every story has direct business value. Refactors, patches, and infrastructure updates don’t map neatly to user outcomes. And value often emerges only after multiple cohesive stories are released. Instead of forcing stories to be valuable in isolation, align them to business outcomes. Insistence that stories must be estimatable may pressure teams into unreliable guesses. And what about #NoEstimates? Teams are better off using flow-based forecasting and probabilistic methods. Small stories can create fragmentation. Stories must be manageable, but atomizing them can disconnect work from value. Create thin vertical slices, not arbitrary chunks. Testability refers to functional tests, but what about usability, accessibility, and performance? A feature may pass tests but fail real-world adoption. Teams need to think beyond pass/fail and consider UX. FOCUS I propose a new approach aligned with modern Agile practices: F = Flow-Oriented: Optimize end-to-end value delivery, reducing bottlenecks instead of forcing artificial independence. O = Outcome-Driven: Frame stories around business/user outcomes, not just functional reqs. C = Collaborative & Clear: Co-create stories across teams to achieve shared understanding with clear acceptance criteria. U = Usability-Centric: Factor in usability, accessibility, and performance, not just technical functionality. S = Sustainable & Sliced: Right-size stories for sustainable development, emphasizing thin vertical slices over fragmented work. Why FOCUS Works FOCUS solves challenges like dependencies, UX gaps, and fragmented backlogs. It encourages system thinking over simplistic story breakdowns, aligns with Story Mapping and Flow Metrics, and promotes sustainable delivery - building better, not just shipping faster. Stop INVESTing. Start FOCUSing. INVEST served us well, but it doesn’t address today’s complexities. If your team struggles with fragmented stories, unclear value, and over-reliance on estimation, it’s time to FOCUS.

Most BAs never meet the people they build for. I learned this the hard way. Everything changed the day I heard a user’s frustration firsthand. I was on a project where we spent weeks arguing, dissecting, and 'analysing' a feature. None of us knew what the end users actually did. Or what they needed. We were guessing. The funny part is that the answer took 10minutes once we spoke to users. This is the quiet problem in many teams. Actually not quiet, but HUGE problem I see. Business Analysts and Product Owners are stuck in multiple meetings, docs, and Jira tickets. Without ever hearing, feeling or understanding real user pain. Then they get blamed when the solution misses the mark. If you want a BA to do great work, give them access. Let them hear the frustration in a user’s voice. Let them see their workarounds. Let them watch what really happens, not what a stakeholder thinks happens. Here is what changes when a BA speaks to users: → Requirements are more targeted ↳ You stop guessing and start solving the real problem. → Misaligned stakeholders calm down ↳ User facts beat internal opinions. → Delivery speeds up ↳ You avoid rework because you know what matters. → The BA starts thinking like a product owner ↳ They connect decisions to impact, not tasks. Every product team says we’re "user-centric". Few actually act like it. Your BA can’t drive clarity from the sidelines. Let them into the real world so they can bring truth back to the team. What stops BAs in your company from talking to real users? ♻️ Repost to help more BAs escape guesswork ➕ Follow Patrick Giwa, PhD for more

Design iteration can get messy. It's usually controlled during production because engineering teams follow structured, logic-based processes that are hard to change quickly. However, these controls need to be more flexible to unlock the full value of design. Alessandro Trezzi has a great question on my last design iteration post. “How do you see iteration working within agile sprints?” Paraphrasing, he observes that once a feature ships, it’s often seen as "done" unless market pressure demands changes. Iteration usually happens only during development, while later improvements end up in a backlog that’s often ignored as new priorities take over. 🚀 Here’s how we approach this scenario: Design doesn’t follow a single track because it involves overlapping cycles. To manage this, we use three different mindsets. UX metrics are common across all tracks, which help us align discussions, communicate clearly with stakeholders, and connect the work to its design impact. Concept Track ↳ Create and improve ideas by gathering user feedback to ensure they’re ready before building. Production Track ↳ Turn improved ideas into prototypes and fully developed designs for real-world use. Analytics Track ↳ Track how live designs perform to decide if they should stay, be updated, or be replaced. 🤔  What does this mean? 1. Flexibility over strict processes ↳ Different tracks (concept, production, analytics) have their own timelines, which can vary weekly. Keeping them aligned requires flexibility because not every problem can be solved in a week, a month, or even a year. Example: If a feature idea takes months to develop but analytics need to be tracked weekly, the team should focus on gradual improvements without forcing rushed solutions. 2. Use UX metrics to bridge mindsets ↳  UX metrics connect ideas across all three mindsets (concept, production, analytics). These metrics can reveal opportunities to link cause and effect in the work. Example: Track "time on task" to see how initial design concepts evolve into prototypes, eventually impacting usability when live. 3. Involve the whole team in feedback ↳  Include everyone in feedback sessions so the origins of ideas are clear and everyone knows which assumptions will be tested during production. Example: During a review meeting, designers, engineers, and advocates discuss which prototype features are based on user feedback and what will be measured in live testing. 4. Align analytics to original assumptions ↳  Analytics should stay focused on the initial assumptions. Broad or vague data doesn’t build confidence in the results. Example: Instead of reporting general user activity, measure specific metrics, like whether a new navigation menu reduced task completion times as intended. We can explore ideas as needed in the conceptual track, using research to evaluate new directions. For most companies, design teams usually focus on improving and building upon an existing product. What's your approach?

Not a hack: Want your engineers to be more user-centric? Introduce them to the why-how laddering exercise. Instead of jumping to “we need a notification system,” you climb up with “why”: 🟡"Why add notifications?" → "Users miss important updates" 🟡"Why do they miss them?" → "They only check weekly" 🟡"Why is that a problem?" → "Issues compound, causing frustration" Then back down with “how”: 🟡"How to keep them informed?" → "Alert for critical changes" 🟡"How to define critical?" → "When action is needed within 24h" 🟡"How to implement?" → "Start with email, add push later" This is also useful during interviews: note who asks "why" before proposing "how," it reveals engineers who think in problems, not just features. In hundreds of technical interviews, you'll find maybe one or two engineers who instinctively start investigating the problem before diving into solutions. Centering Gemography's vetting process (we help teams scale with pre-vetted remote product engineers) around this kind of thinking has changed the game for us and our clients. Once you go user-centric, you can't go back. Nurture the mindset, and hire for it.

Product launches in the startup world notoriously fail to achieve sustained usage, not because of flawed technology, but due to a fundamental misdefinition of 'delivery.' I’ve observed too many teams, with immense talent, celebrating code shipped—the MVP is out!—only to be blindsided by anemic adoption rates just weeks later. This exact scenario played out in a previous venture where we pushed a highly polished feature. Our internal metrics were green, every bug squashed. Yet, after 90 days, only 18% of target users integrated it into their daily workflow. The core issue? We optimized for 'go-live' rather than 'behavioral change,' mistaking shipping for user adoption. The critical insight isn't about better features, but about creating continuous systems focused on user behavior adoption. This requires a dedicated 'adoption loop' framework: not sequential handoffs, but deeply integrated cross-functional teams aligned on one single adoption metric. The tactical implementation involves daily huddles where the team doesn't just discuss bugs, but user friction points, workarounds, and how new habits can be facilitated. This shifts 'work' from building code to actively facilitating behavioral change. The non-obvious connection? Sustained product growth maps less to a linear development process and more to a perpetual cycle of anthropological study combined with agile execution. Considering this, what's a specific internal metric or team structure you’ve found most effective in measuring and driving true user adoption post-launch, beyond just initial engagement?

We used to build products like an assembly line. Recently, I shared how we shifted from an "output" mindset to an "outcome" mindset at Avoma. That was just the surface. Underneath, something deeper was happening – a rewiring of how our teams think, behave, and collaborate. These shifts weren’t just tactical. They were cultural. Here are 4 mindset shifts we’ve made that changed how we build – and more importantly, why we build what we do. 𝟭. 𝗢𝘂𝘁𝗰𝗼𝗺𝗲 > 𝗢𝘂𝘁𝗽𝘂𝘁 This one’s foundational. It’s not about completing tasks or shipping features; it’s about delivering an outcome and making an impact. Instead of “What did we launch?”, the question becomes “Did it help the customer win more deals?”, “Did it save them time?”, etc. Engineers need to ask, “How will this change what the customer does?” instead of “When do we go live?” 𝟮. 𝗖𝘂𝘀𝘁𝗼𝗺𝗲𝗿-𝗰𝗲𝗻𝘁𝗿𝗶𝗰 (𝗳𝗼𝗿 𝗿𝗲𝗮𝗹 𝘁𝗵𝗶𝘀 𝘁𝗶𝗺𝗲) Everyone says they’re customer-centric. But the "centric" part means the customer is at the center – not your design system, data model, old architecture, or resource constraints. Too often, we prioritize “what’s easier for us” over “what’s better for them.” The hard truth? The customer doesn’t care about your tech stack. They care about their problem being solved. We started making product decisions with the customer in the room (figuratively), asking: What would they choose if they were sitting here with us? 𝟯. 𝗖𝗿𝗼𝘀𝘀-𝗳𝘂𝗻𝗰𝘁𝗶𝗼𝗻𝗮𝗹 𝗳𝗿𝗼𝗺 𝘁𝗵𝗲 𝘀𝘁𝗮𝗿𝘁 A lot of teams say they’re agile, but still operate like waterfall in disguise. PM does the research → design mocks up solutions → eng builds it → QA tests. It’s linear. It’s slow. It’s siloed. Now, we bring product, design, and engineering together at the start – before there’s even a solution. Everyone has a seat at the table when we’re 𝘀𝘁𝗶𝗹𝗹 𝗷𝘂𝘀𝘁 𝗱𝗲𝗳𝗶𝗻𝗶𝗻𝗴 𝘁𝗵𝗲 𝗽𝗿𝗼𝗯𝗹𝗲𝗺. And the magic? Engineers come up with product ideas. Designers push technical boundaries. PMs get challenged on assumptions. 𝟰. 𝗩𝗶𝘀𝘂𝗮𝗹 𝗰𝗼𝗹𝗹𝗮𝗯𝗼𝗿𝗮𝘁𝗶𝗼𝗻 𝗼𝘃𝗲𝗿 𝘄𝗮𝗹𝗹𝘀 𝗼𝗳 𝘁𝗲𝘅𝘁 Slack threads. Long PRDs. Endless documentation. That’s how you 𝗱𝗼𝗰𝘂𝗺𝗲𝗻𝘁 decisions. Not how you 𝗺𝗮𝗸𝗲 them. With Vibe coding on the rise, we started pushing for visual thinking early – rough sketches, clickable prototypes – anything that brings ideas to life. When you see a customer journey, it’s easier to feel where the friction is. When you mock something quickly, others can riff on it. It’s messy, but that mess is where clarity emerges. The truth is, changing how we build wasn’t just a process update. It was a mindset evolution. And the biggest unlock? We stopped trying to be "𝗿𝗶𝗴𝗵𝘁 𝘂𝗽𝗳𝗿𝗼𝗻𝘁" and started trying to get it "𝗿𝗶𝗴𝗵𝘁 𝘁𝗼𝗴𝗲𝘁𝗵𝗲𝗿".

𝗨𝘀𝗲𝗿 𝗦𝘁𝗼𝗿𝗶𝗲𝘀 𝘃𝘀. 𝗨𝘀𝗲 𝗖𝗮𝘀𝗲𝘀: 𝗪𝗵𝗲𝗻 𝘁𝗼 𝗨𝘀𝗲 𝗪𝗵𝗮𝘁? 🤔 𝗨𝘀𝗲𝗿 𝗦𝘁𝗼𝗿𝗶𝗲𝘀: Short, simple descriptions of a feature from the end-user’s perspective.  𝗕𝗲𝘀𝘁 𝗙𝗼𝗿: • Agile environments (Scrum/Kanban) • High-level, flexible requirements • Projects that involve quick iterations and continuous feedback 𝗨𝘀𝗲 𝗖𝗮𝘀𝗲𝘀: Detailed descriptions of how users interact with a system, including steps, exceptions, and preconditions. 𝗕𝗲𝘀𝘁 𝗙𝗼𝗿: • Complex systems with multiple steps/scenarios • Waterfall or hybrid projects (rarely for Agile Projects) • Technical teams require detailed process flows 💡 𝗧𝗵𝗲 𝗛𝘆𝗯𝗿𝗶𝗱 𝗔𝗽𝗽𝗿𝗼𝗮𝗰𝗵: 𝗨𝘀𝗲𝗿 𝗦𝘁𝗼𝗿𝗶𝗲𝘀 + 𝗨𝘀𝗲 𝗖𝗮𝘀𝗲𝘀 Here’s where things get interesting! In many Agile teams, especially those working on complex features, combining 𝗨𝘀𝗲𝗿 𝗦𝘁𝗼𝗿𝗶𝗲𝘀 with 𝗨𝘀𝗲 𝗖𝗮𝘀𝗲 𝗱𝗲𝘁𝗮𝗶𝗹𝘀 can be a valuable approach. How? • Keep the User Story format for the high-level view. • Add Use Case steps, flows, or exceptions in the description 𝗨𝘀𝗲𝗿 𝗦𝘁𝗼𝗿𝘆: 𝘈𝘴 𝘢 𝘱𝘢𝘵𝘪𝘦𝘯𝘵, 𝘐 𝘸𝘢𝘯𝘵 𝘵𝘰 𝘴𝘤𝘩𝘦𝘥𝘶𝘭𝘦 𝘢𝘯 𝘢𝘱𝘱𝘰𝘪𝘯𝘵𝘮𝘦𝘯𝘵 𝘰𝘯𝘭𝘪𝘯𝘦, 𝘴𝘰 𝘵𝘩𝘢𝘵 𝘐 𝘤𝘢𝘯 𝘦𝘢𝘴𝘪𝘭𝘺 𝘮𝘢𝘯𝘢𝘨𝘦 𝘮𝘺 𝘩𝘦𝘢𝘭𝘵𝘩𝘤𝘢𝘳𝘦 𝘷𝘪𝘴𝘪𝘵𝘴. 𝗗𝗲𝘀𝗰𝗿𝗶𝗽𝘁𝗶𝗼𝗻 (𝗨𝘀𝗲 𝗖𝗮𝘀𝗲 𝗗𝗲𝘁𝗮𝗶𝗹𝘀): 1. 𝗣𝗿𝗲𝗰𝗼𝗻𝗱𝗶𝘁𝗶𝗼𝗻: Patient is logged in. 2. 𝗠𝗮𝗶𝗻𝗳𝗹𝗼𝘄: • Navigate to the 'Appointments' tab. • Select the preferred date/time. • Confirm appointment. • Receive confirmation email. 𝗔𝗹𝘁𝗲𝗿𝗻𝗮𝘁𝗲 𝗙𝗹𝗼𝘄: If the slot is unavailable, suggest the next available time. 𝗔𝗰𝗰𝗲𝗽𝘁𝗮𝗻𝗰𝗲 𝗖𝗿𝗶𝘁𝗲𝗿𝗶𝗮: ***************** 𝗪𝗵𝘆 𝗜 𝗙𝗲𝗲𝗹 𝗧𝗵𝗶𝘀 𝗜𝘀 𝗮 𝗚𝗼𝗼𝗱 𝗔𝗽𝗽𝗿𝗼𝗮𝗰𝗵: 𝗕𝗿𝗶𝗱𝗴𝗲𝘀 𝘁𝗵𝗲 𝗚𝗮𝗽: User Stories keep things user-focused, while Use Cases add the technical depth that dev teams need. 𝗥𝗲𝗱𝘂𝗰𝗲𝘀 𝗔𝗺𝗯𝗶𝗴𝘂𝗶𝘁𝘆: Developers get both what the user needs and how the system should behave and reduce back-and-forth discussions. 𝗦𝘂𝗽𝗽𝗼𝗿𝘁𝘀 𝗖𝗼𝗺𝗽𝗹𝗲𝘅𝗶𝘁𝘆: For simple tasks, a User Story is enough. For complex workflows, adding Use Case details ensures no step is missed. 💬 Do you combine User Stories and Use Cases in your Agile projects? I'd love to hear your thoughts on this! 👇 #Agile #Scrum #UserStories #UseCases #BusinessAnalysis #ProductManagement #BA #SoftwareDevelopment #AgileBestPractices

🧩 User Story Mapping: The Bridge Between Process Mapping & Product Vision As a Business Analyst, translating messy, unstructured needs into clear, prioritized deliverables is core to what we do. But how do we visualize that journey? Enter: User Story Mapping — a process-centric tool that’s visual, collaborative, and rooted in real user behavior. 🎯 What You’re Looking At: This isn’t just a board of sticky notes. It’s a structured process map showing: 🔹 User Activities (Backbone) — High-level goals like “Organize Email” or “Manage Calendar” 🔹 Tasks (Walking Skeleton) — Core user flows broken down into actionable steps 🔹 User Stories — Incremental pieces, grouped by release and priority. 📌 Instead of flat backlogs, this format gives: ✅ Context ✅ Prioritization ✅ Release planning ✅ Process visibility 💡 Real-World Value: In one of my past projects, using this approach for a client-facing portal helped align developers, testers, and stakeholders in one conversation. It turned out to be the blueprint for both our agile backlog and our QA testing strategy. 👣 Takeaway Process Mapping isn’t limited to swimlanes and flowcharts — it’s also about sequencing actions that reflect real user journeys. And when you lay those out visually, you don’t just understand the process — you start shaping the product. 💬 Have you used User Story Mapping in your projects? What tools or formats worked best for you? #BusinessAnalysis #UserStoryMapping #ProcessMapping #ProductThinking #AgileDelivery #BusinessAnalyst #StoryMapping #Jira #UserCentricDesign

Every product that doesn’t put users first will fail. Here’s the exact 7-step product development playbook we use to grow Sprig: 1. Identify an actual* problem/need. The worst mistake a Product team can make is forging ahead without pinpointing how a product will help their target customer. It doesn’t matter how good the product is if nobody wants it. The right way to do this conducting generative research (generative interviews and field studies) to better understand what your users want. 2. Design how to solve their job to be done. Once you’ve identified a need, the “jobs to be done” framework is your best friend. When people purchase products, they “hire” the product to do a job for them. Your Product Designer’s only job is to build a product that can do the job better than existing solutions. 3. Create a minimum lovable product. Post-design, you build an MLP—Minimum Lovable Product. The problem with minimum viable* products is that the user gets a flawed version of the product. Minimum lovable products focus on 1 or 2 features that truly delight the user. Credit to Jiaona Zhang (JZ) for the framework! 4. Test the prototype with your end users. After you create, you test. Get it in front of users, and use evaluative research to validate your products’ potential. 5. Build benefits, not features. Nobody cares about features. Your users need a problem solved. As you build the prototype into a real product, keep a stubborn focus on a few core high-value benefits for your users. NOTE: At this stage, it’s also important for PMs to be able to say no to feature requests! 6. Launch a full-blown customer experience. Your product’s experience* is just as (if not, more) important than the product itself. Some tips to help you create a wonderful experience: → Use plain language within your product → Create a robust knowledge base for users → Offer human customer support for more challenging issues. → Give users a place to leave feedback (and feel heard!). 7. Use Continuous Research to ship valuable updates For as long as you develop your product (always), your users’ needs must be top of mind. In-product surveys plus other in-product methods of collecting feedback are the best way to handle this. (Sprig can help here, comment or DM and we’ll get you started) That was a lot, but I hope it was helpful. Let me know if you have any questions!

🎬 Episode 4: Helping Teams Fall in Love With the Problem Because solving the right problem beats building the perfect solution. Scrum Masters and Coaches — let’s talk truth: 🚫 Too many teams get stuck chasing “done.” ✅ But the best ones chase understanding. You want innovation? You want real impact? Then don’t rush to the solution. Teach your teams to sit with the problem. Dissect it. Empathize with it. Fall in love with it. ____________________________________________ 💔 The Problem with Solution Obsession: Teams often jump from idea → ticket → delivery …but skip the most important step: Why does this matter? That’s how you end up with well-built features that no one uses. ___________________________________________ 💡 Shift the Focus: Problem First, Always As a coach, you can guide this shift by: 1️⃣ Creating Space for Discovery → Before story refinement, ask: What’s the actual pain point here? Have we heard this from real users? 2️⃣ Using Problem Statements, Not Just User Stories → Encourage teams to craft “How might we…” questions to explore the problem fully. 3️⃣ Bringing Customers Into the Room → Literal or metaphorical. Use feedback, data, recordings — anything that keeps the user real. 4️⃣ Celebrating Curiosity → Praise questions like: “Do we need to solve this now?” “What if we didn’t build anything?” Curiosity drives clarity. 5️⃣ Zooming Out, Regularly → Revisit product goals. Are we solving isolated issues… or moving toward a larger outcome? _________________________________________________ 🔆 The Power of Problem-Centric Coaching: ✅ Teams build smarter. ✅ POs prioritize sharper. ✅ Products grow with purpose. And you? You become the coach of clarity — the one who unlocks thinking before building. ______________________________________________________ 📌 Are your teams solving problems… or just delivering solutions? 💬 Share one way you help teams explore the why before the what 👇 👥 Tag someone who leads with curiosity. #AgileCoach #ScrumMaster #ProblemSolving #ProductMindset #AgileLeadership #FallInLoveWithTheProblem #DesignThinking #LeadingTheProductMindset #Episode4 #LinkedInSeries