Integrating User Feedback in Agile Development

Testing with users isn’t just for the end. Or is it? I love Artiom Dashinsky’s take that vibe coding lets him validate ideas with real users much faster. Instead of running upfront research, he watches what people do, fixes issues on the fly, and ships new ideas directly into production.(https://lnkd.in/gc_U2w9Z) That kind of fast energy is exciting. It’s harder to do with big teams or strict systems that have a lot of compliance, but it points to a future where building and testing happen at the same time. I can see this leading to better products. But if the value of your product is hidden behind too many steps, users end up doing the hard work just to get through it. That might be okay for simple tools, but in more complex ones, you're turning users into lab mice. There's a middle ground where gut instinct and research work together. In our work with UX metrics in Helio, we see how helpful it is to get quick structured feedback from users while building. As ideas become more complex, it's even more important to know when to test and when to watch. My take is that user testing is useful at every stage of the design process, not just at the end. At each step in ideation, different types of user feedback help guide the work. In the early stage, attitudinal UX metrics help frame the challenge. As the concept develops, behavioral UX metrics help assess potential. Once the product is live, performance metrics help finalize choices. Even if you're moving fast with vibe coding, quick testing with users can help you make stronger design decisions along the way. I’m excited for what’s next. What’s your take- when is user research really needed? #productdesign #uxmetrics #productdiscovery #uxresearch

I've seen my fair share of product development processes. JPD's approach stands out as particularly principled and well thought out. Here are the five most important things about how they build product: 𝗙𝗮𝗰𝗲𝘁 𝗢𝗻𝗲 - 𝗧𝗵𝗲 𝗟𝗶𝗴𝗵𝘁𝗵𝗼𝘂𝘀𝗲 𝗣𝗵𝗶𝗹𝗼𝘀𝗼𝗽𝗵𝘆 As Catalin Bridinel, Head of Design, explains: "The product is a ship, and the user is a lighthouse that gives you direction." This is more than a cute metaphor - it's a fundamental operating principle that multiple interviewees brought up. It manifested, for instance, in the early access program stages: Step 1 - Deep dive with 10 carefully selected customers Step 2 - Expand to 100 customers for broader validation Step 3 - Then 1000 and GA And it does in a million little other ways. 𝗙𝗮𝗰𝗲𝘁 𝗧𝘄𝗼 - 𝗧𝗵𝗲 𝗧𝗲𝗮𝗺 𝗦𝘁𝗿𝘂𝗰𝘁𝘂𝗿𝗲 They have Five Autonomous Squads: 1. PM Experience Squad: Focused on core product manager workflows 2. Admin Experience Squad: Handling the critical but often overlooked admin experience 3. Cross-flow Integration Squad: Making JPD play well with the broader Jira ecosystem 4. Infrastructure Squad: Ensuring performance at scale 5. Growth Squad: Driving adoption and expansion Having each squad own specific components end-to-end has transformed their development process. As Edouard Kaiser, Head of Engineering, put it: "Before, everyone owned everything - which meant no one owned anything." JPD operates with a surprisingly lean team of about 50 people, including just 3 PMs (plus Tanguy). 𝗙𝗮𝗰𝗲𝘁 𝗧𝗵𝗿𝗲𝗲 - 𝗧𝗵𝗲 𝗣𝗹𝗮𝗻𝗻𝗶𝗻𝗴 𝗖𝗮𝗱𝗲𝗻𝗰𝗲 Instead of rigid quarterly planning, they've adopted a "nested timeframe" approach: 1. Strategic Planning (Every 6 Months): - Create opportunity solution trees - Define key strategic bets - Align on major initiatives 2. Weekly Rhythm: - Monday: PM Loom updates (3-5 minutes each) - Wednesday: PM sparring sessions - Friday: "Dojo" sessions for deep dives 𝗙𝗮𝗰𝗲𝘁 𝗙𝗼𝘂𝗿 - 𝗧𝗵𝗲 𝗖𝘂𝘀𝘁𝗼𝗺𝗲𝗿 𝗖𝗼𝗻𝗻𝗲𝗰𝘁𝗶𝗼𝗻 𝗘𝗻𝗴𝗶𝗻𝗲 They stay connected. 1. Weekly PM Rotation: - One PM owns all feedback channels - Monitors community posts - Reviews support tickets - Catalogues sales feedback 2. Video-First Customer Understanding: - Every product decision includes customer video clips - Regular customer interview reels - Visual evidence over written summaries This allows PMs to have a near-Tanguy level knowledge and understanding of the product. 𝗙𝗮𝗰𝗲𝘁 𝗙𝗶𝘃𝗲 - 𝗕𝘂𝗶𝗹𝗱𝗶𝗻𝗴 𝗶𝗻 𝗣𝘂𝗯𝗹𝗶𝗰 In a delightful bit of dogfooding, JPD uses their own product to manage their development process. Their public roadmap isn't just a marketing tool - it's their actual working document. This transparency creates an interesting dynamic: they're building a product management tool while publicly showing how they manage their own product. It's a level of authenticity that I find refreshing.

User research is great, but what if you do not have the time or budget for it........ In an ideal world, you would test and validate every design decision. But, that is not always the reality. Sometimes you do not have the time, access, or budget to run full research studies. So how do you bridge the gap between guessing and making informed decisions? These are some of my favorites: 1️⃣ Analyze drop-off points: Where users abandon a flow tells you a lot. Are they getting stuck on an input field? Hesitating at the payment step? Running into bugs? These patterns reveal key problem areas. 2️⃣ Identify high-friction areas: Where users spend the most time can be good or bad. If a simple action is taking too long, that might signal confusion or inefficiency in the flow. 3️⃣ Watch real user behavior: Tools like Hotjar | by Contentsquare or PostHog let you record user sessions and see how people actually interact with your product. This exposes where users struggle in real time. 4️⃣ Talk to customer support: They hear customer frustrations daily. What are the most common complaints? What issues keep coming up? This feedback is gold for improving UX. 5️⃣ Leverage account managers: They are constantly talking to customers and solving their pain points, often without looping in the product team. Ask them what they are hearing. They will gladly share everything. 6️⃣ Use survey data: A simple Google Forms, Typeform, or Tally survey can collect direct feedback on user experience and pain points. 6️⃣ Reference industry leaders: Look at existing apps or products with similar features to what you are designing. Use them as inspiration to simplify your design decisions. Many foundational patterns have already been solved, there is no need to reinvent the wheel. I have used all of these methods throughout my career, but the trick is knowing when to use each one and when to push for proper user research. This comes with time. That said, not every feature or flow needs research. Some areas of a product are so well understood that testing does not add much value. What unconventional methods have you used to gather user feedback outside of traditional testing? _______ 👋🏻 I’m Wyatt—designer turned founder, building in public & sharing what I learn. Follow for more content like this!