Defining Meaningful Product Requirements
•Descargar como PPTX, PDF•
1 recomendación•181 vistas
Defining new product or service requirements is often treated as a tedious task to slog through so that the “real work” — design and development — may begin. But the largest market opportunities usually come from identifying an unmet need that others have overlooked, rather than simply improving interface design or tweaking features. How can we identify these unmet needs? By taking a step back and conducting a more meaningful process. This workshop will address the four high level areas necessary to build a solid base of requirements: business drivers, user needs, technology frameworks and environmental/social impact. We will work through how to ensure user needs are at the heart of your planning, how to craft requirements that can be flexibly adapted to an Agile process, and how to negotiate effectively with your other stakeholders. This is a hands-on, fast-paced workshop that will leave you with tangible tools that you can take back to your organization and share for maximum impact.
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a Defining Meaningful Product Requirements
Similar a Defining Meaningful Product Requirements (20)
Más de UXPA International
Más de UXPA International (20)
Último
Último (20)
Defining Meaningful Product Requirements
- 1. Defining Meaningful Product Requirements Kathryn E. Campbell Research Manager, Instagram Well-being @sparks_kc #UXPA2021
- 2. 2 WHY WE’RE ALL HERE TODAY Agenda 1:30 Introductions 1:45 Expanding our thinking about requirements 2:45 Break 3:00 Priorities & themes 4:00 Break 4:15 Putting it into action 5:00 Q&A and wrap up @sparks_kc #UXPA2021
- 3. 3 WHY WE’RE ALL HERE TODAY What reaction do you have when you hear someone talk about requirements gathering? @sparks_kc #UXPA2021
- 4. 4 WHY WE’RE ALL HERE TODAY What is your organization’s process for requirements gathering? @sparks_kc #UXPA2021 Often, the process is: • Gather a list of features that have been discarded in the past, executive pet ideas, and new competitive features • Jump straight to documentation • Little cross-disciplinary involvement • No outside information gathering
- 5. 5 WHY WE’RE ALL HERE TODAY Let’s re-think requirements gathering! @sparks_kc #UXPA2021
- 6. 6 WHY WE’RE ALL HERE TODAY Let’s re-think requirements gathering! We tend to want to get requirements as quickly as possible so we can get to design (or development), where we think the magic happens. @sparks_kc #UXPA2021
- 7. 7 WHY WE’RE ALL HERE TODAY Let’s re-think requirements gathering! But in reality, most of the insights that will determine success happen during the discovery/requirements phase. “Make sure you are building The Right It before you build it right.” ― Alberto Savoia, Google’s Innovation Agitator, Author @sparks_kc #UXPA2021
- 8. 8 WHY WE’RE ALL HERE TODAY The BUTI of solid requirements There are four high level areas we should consider to build a solid base of requirements: • Business drivers • User needs • Technology framework • Impact @sparks_kc #UXPA2021
- 9. 9 WHY WE’RE ALL HERE TODAY The BUTI of solid requirements “Teams that attain a shared understanding are far more likely to get a great design than teams who fail to develop a common perception of the project’s goals and outcome.” ― Jared Spool, Author and founding Principal of of User Interface Engineering @sparks_kc #UXPA2021
- 10. 10 WHY WE’RE ALL HERE TODAY The BUTI of solid requirements And that benefits from input from a diverse group of people: • Designers • Engineers • Researchers • Marketing & Salespeople • Operations • Customer Service Reps • Product Managers @sparks_kc #UXPA2021
- 11. 11 THE BUTI OF SOLID REQUIREMENTS Sources of Business Requirements • Competitive analysis • Industry trend stories, emergence of new competition (including indirect) • Financial analysis (growth, margins, pareto analysis) • Brand & marketing research surveys • Sales & customer service requests & complaints • Social media sentiment analyses @sparks_kc #UXPA2021
- 12. 12 THE BUTI OF SOLID REQUIREMENTS Sources of User Requirements • Sales & customer service requests & complaints • Social media sentiment analyses • Product concept surveys & interviews • Personas @sparks_kc #UXPA2021
- 13. 13 THE BUTI OF SOLID REQUIREMENTS Sources of Tech requirements: • Existing tech stack • Compatible integrations • Planned upgrades • Depth of Eng team skills • User constraints @sparks_kc #UXPA2021
- 14. 14 THE BUTI OF SOLID REQUIREMENTS Impact Considerations • L – Who are we Leaving out? (other abled, economically disadvantaged, minorities) • E - Environmental waste or destruction • A - Potential for misuse by bad Actors • V - Disproportionate impact on Vulnerable populations (LGBTQ, domestic violence victims, unhoused) • E – Consequences of Extreme success on users, communities, workers @sparks_kc #UXPA2021
- 15. Let’s do this! @sparks_kc #UXPA2021
- 16. 16 THE EXERCISE Farm2Me, a farm-to-table grocery app @sparks_kc #UXPA2021 A consortium of small produce and dairy farmers want to create a direct-to-consumer mobile app that allows buyers to get access to their fresh, organic specialty foods delivered regularly to their door.
- 17. 17 THE EXERCISE Some business insights @sparks_kc #UXPA2021 • The most valued brand attributes include connection to the source of food, quality, and convenience. • While this is not a low-cost service, it is not meant to be exclusive either. We want to connect more people to locally produced food. • A new customer has to order at least three times for us to break even on setup costs.
- 18. 18 THE EXERCISE Persona: Sun, 41 • Busy investment professional. • Married, mother of two children, ages 7 and 10. • Good cook, but she often has to work late. Cooks more on weekends. • Willing to pay for convenience and high quality. • Lives in a secure high rise building. @sparks_kc #UXPA2021
- 19. 19 THE EXERCISE Persona: Mickey, 26 • Chiropractic assistant. • Single. • Still learning how to cook for himself. Trying to eat less meat, learn vegan options. • On a budget. • Shares a small house with two friends. They occasionally cook group meals together. @sparks_kc #UXPA2021
- 20. 20 THE EXERCISE Persona: Jamal, 35 • Computer science instructor. • Tends to eat a lot of frozen & deli meals. • Comfortable financially. Really values speedy delivery. • In a long distance relationship, currently lives by himself in an apartment. Often works late when he teaches night classes. @sparks_kc #UXPA2021
- 21. 21 THE EXERCISE Exercise 1: brainstorm potential requirements for Farm2Me @sparks_kc #UXPA2021
- 22. Writing a good requirement @sparks_kc #UXPA2021
- 23. 23 ARTICULATING REQUIREMENTS Refining requirements The perfect requirement: • Clearly explains the what and the why • Does not dictate the how @sparks_kc #UXPA2021
- 24. 24 ARTICULATING REQUIREMENTS Refining requirements Why you should avoid being overly prescriptive during requirements: • There are many possible solutions to any problem • Sprints are the best place to explore those tradeoffs @sparks_kc #UXPA2021
- 25. 25
- 26. 26 ARTICULATING REQUIREMENTS Exercise 2: revise requirements you drafted Take 1 - 2 requirements that you drafted earlier • Make sure the What & Why are clearly articulated • Remove any reference to the How • Outline several different solutions that would fulfill the requirement as written @sparks_kc #UXPA2021
- 29. 29 PRIORITIZATION Prioritizing features Prioritization involves assessing Value vs. Effort • Start by scoring each feature by value • To each persona • To our business • To the broader community @sparks_kc #UXPA2021
- 30. 30 PRIORITIZATION Feature prioritization @sparks_kc #UXPA2021 This Prioritization Matrix was developed by LA agency Primitive Spark and should be credited when used. Find a sample at https://bit.ly/3gN6bFR Feature Matrix Value (0-10) . Effort . Grand Total >>> Weighting >>> 8 4 7 10 7 1 5 5 1 >>> Column Heading >>> Sun Mickey Jamal Business Impact Value Total Build Maintain Effort Total Support safe hygiene in delivery 9 6 9 9 10 319 6 4 50 269 Trace product origins 9 6 8 10 10 322 9 6 75 247 Specify personal preferences to get a more custom-tailored delivery 8 6 10 7 6 270 4 5 45 225 Make allergen information readily available 9 6 3 8 10 267 5 5 50 217 Don't have to remember to order 8 4 8 8 6 258 3 6 45 213 Deliver goods to users’ homes when they are not present to help them save time 10 4 10 6 7 275 7 8 75 200
- 31. 31 IN ACTION Use themes to focus roadmaps & plan sprints “A theme is a group of features tied together by a simple, clear benefit, usually to the user.“ Focus on a small number (1 – 3) of overarching themes oriented around solving customer problems. Exclude distracting features that don’t relate to the problem at hand. @sparks_kc #UXPA2021 Reference articles by Bruce McCarthy & Jared Spool
- 32. 32 PRIORITIZATION Feature prioritization @sparks_kc #UXPA2021 This Prioritization Matrix was developed by LA agency Primitive Spark and should be credited when used. Find a sample at https://bit.ly/3gN6bFR Theme Feature Matrix Value (0-10) . Effort . Grand Total Phase >>> Weighting >>> 8 4 7 10 7 1 5 5 1 >>> Column Heading >>> Sun Mickey Jamal Busines s Impact Value Total Build Maintain Effort Total Delivery Support safe hygiene in delivery 9 6 9 9 10 319 6 4 50 269 1 Safety Trace product origins 9 6 8 10 10 322 9 6 75 247 1 Delivery Specify personal preferences to get a more custom- tailored delivery 8 6 10 7 6 270 4 5 45 225 1 Safety Make allergen information readily available 9 6 3 8 10 267 5 5 50 217 1 Delivery Don't have to remember to order 8 4 8 8 6 258 3 6 45 213 1 Delivery Deliver goods to users’ homes when they are not present to help them save time 10 4 10 6 7 275 7 8 75 200
- 33. 33 IN ACTION Key to success: learn how to say no Complexity builds up inexorably over time • Feature creep • Competitive reactions • Executive comments @sparks_kc #UXPA2021
- 34. 34 IN ACTION Some ways to say no (and not get fired) Ways to keep your roadmap from getting unwieldy • Use themes to enforce focus • Let your users deliver the bad news • Measure perceived complexity • Regularly measure & report on features that are rarely used • Enforce a “feature swap” rule @sparks_kc #UXPA2021
- 35. Requirement Gathering in Action @sparks_kc #UXPA2021
- 36. 36 IN ACTION Bring it together A typical inception/discovery process might include: • Background research • Stakeholder interviews • Customer research • Creating a summary package • One day workshop @sparks_kc #UXPA2021
- 37. 37 IN ACTION Making it Agile • Continuously share & discuss relevant external data • Refine requirements together each sprint • Validate along the way @sparks_kc #UXPA2021 Requirements Sprint planning Design/Analysis Implement/Test Retro/Learn
- 38. 38 IN ACTION Continuous validation techniques Democratizing Research – leveraging other team members to conduct routine usability testing Rolling Research – routinely scheduled validation windows for each sprint @sparks_kc #UXPA2021
- 39. 39 WHAT WE COVERED Ticketmaster confidential. Do not distribute. The recap @sparks_kc #UXPA2021
- 41. 41 WHAT WE COVERED Ticketmaster confidential. Do not distribute. Take aways • Think big and BUTI-ful! Consider business, user, tech and impact based requirements • Use personas to consider user needs in a detailed way • Don’t shortcut the creative process with prescriptive requirements • Prioritize objectively, group thematically • Say no more often • You can move more quickly with user validation @sparks_kc #UXPA2021
Notas del editor
- Introduce myself Call out twitter info Have others intro themselves: name, role, experience with requirements definition in their org Review agenda, breaks, ground rules: Cell off Wear mask Actively participate!
- First of all, thank you to all who have joined me today to talk about requirements definition! You guys are either crazy or just insanely dedicated. What are some words you associate with requirements gathering? [ASK FOR INPUT] We view RG as tedious, time consuming. How long does it typically take at your company? [ASK FOR INPUT] And what do we usually do? [ASK FOR INPUT]
- Take a bunch of requests from management, look at what competitors are doing, add some backlog items, and throw it all into a spreadsheet or Jira, and say, “okay, here are the requirements.”
- We tend to think of RG as the vegetables that we’re forced to eat before we can get to the dessert (i.e. design or development) Flip your mindset – THIS is where the magic happens! This our chance to identify something really interesting that could change our business.
- I was really struck by this quote when I first saw it, because it encapsulates what I have observed over the years. In an effort to move more quickly, companies end up instead chasing their tails and wasting time and resources. Moving more thoughtfully at the beginning of a project usually results in it proceeding more rapidly and efficiently later. Jumping to design -- and certainly going straight to development -- too quickly eliminates the opportunity for expanding your POV, brainstorming, and identifying new opportunities. I can honestly say that I can predict how significant your product will be based on how you approach requirements gathering. Note that I’m not talking about creating a huge amount of documentation here. I’m talking about seeking out information, reframing potential markets, and creatively exploring ideas with your colleagues. Also, let’s set the stage: we’re talking about new products or major releases/upgrades, the kind of project that typically runs at least 6 months to several years, not minor extensions of existing products & features.
- So, what does it take to build the Right It? Looking at your business and your company through fresh eyes, in a comprehensive way.
- So, what does it take to build the Right It? Looking at your business and your company through fresh eyes.
- So, what does it take to build the Right It? Looking at your business and your company through fresh eyes.
- So, what does it take to build the Right It? Looking at your business and your company through fresh eyes. Assess the business landscape the way that a strategist would. If you were building the business today, how would you approach it? [Discuss each point, including Brand]]
- Discuss different sources of user requirements in addition to personas
- In this workshop we’re not going to spend much time on technical requirements -- that would require more time and a broader group of workshop participants. But understanding the constraints and direction that your tech stack is moving is important, and that’s one of many reasons why it’s valuable to include at least one Engineering lead in your requirements definition group from the start. But remember that your competitors may not have the same legacy constraints that you have. Don’t make a tech constraint a requirement, it will guarantee that you fall behind.
- This is the scenario we’re going to use for our activities today
- This is the scenario we’re going to use for our activities today
- Farm2Me has defined a couple of personas they wish to target: Sun and Mickey
- Have one person each do Business & Impacts, Sun, Mickey & Jamal requirements. Stick with one color post its per person. Do Impact & Tech as a group Give 10 minutes for brainstorming, then 5 each for presenting and adding additional ideas. For each consideration area, you’re going to brainstorm and add each idea as a sticky note. For example, if you are in the Business requirements group, what are the demographic trends impacting the industry? What requirements come to mind? For each one, put them on the small post its, and add them to your section of the board.
- There are several dangers to being prescriptive in defining requirements. “Add to wallet” example. The solution for achieving the how should be initiated in this phase as we assess high level difficulty, but can ultimately best be decided in sprint.
- Discuss examples based on requirements so far that could be built in different was with vastly different levels of difficulty.
- Pick 2 requirements that you drafted earlier. Rework them to be specific about the what & why, but not include the how. Review as a group, refine further.
- Should have at least 45 minutes by this slide
- Once you’ve validated assumptions, you can prioritize Discuss how to prioritize
- https://docs.google.com/spreadsheets/d/1HGSkaqX9rTs7onEPlq-gsxgK09426AS1bR071bXuZ0c/edit?usp=sharing Or short: https://bit.ly/3gN6bFR Features to mention: relative value weights Alternative scoring systems How the matrix works Do a few as a group Sort, then go to completed example GROUP EXERCISE: Prioritize features separately for each persona, and also for us as an organization (highest business value)
- How do we help keep our internal users focused? Bruce McCarthy suggests the use of product themes for roadmaps: http://www.productpowers.com/blog/roadmaps-focus-on-vision-benefits-not-features.html Jared Spool article on Product Themes to maintain focus: https://articles.uie.com/themes/
- If time allows, group into value themes Can also use Epics, User Stories Kanban boards We normally work from a spreadsheet with verbal descriptions of capabilities initially. We then prioritize these by user persona. The final step before agreeing on the MVP for launch is to look at level of effort likely for each feature. At that point we will discuss specific ways that a feature might be implemented -- again, more conceptually than specifically. For example, “This might be a fairly challenging 1 month of development effort if it must be custom built, but if we can live with a simple plugin such as this one that’s available for purchase, it would require only a couple of days for integration and testing.” Next get into the roadmapping or sprint planning process.
- SHOULD HAVE AT LEAST 20 MINUTES LEFT AT THIS POINT As Product Owners, we are constantly under siege with requests for new features. Sales team sees a competitive feature, thinks we have to match it. Execs get a random suggestion from their spouse or golf buddy. A customer requested something, so we assume everyone would like that. We still have leftover backlog items from a year ago. However, these additions are almost never offset by a countervailing force to simplify things, so complexity accrues inevitably. I was really struck by a comment made many years ago, during Nokia’s heyday as a mobile phone manufacturer. He stated that 85% of the Nokia phones that were returned “functioned as designed.” They were not defective in the sense that they didn’t work. They were simply unusable.
- It’s important that we continuously reinforce the fact that there are costs to complexity. Cognitive overload and the perception that something is not easy to use creates a barrier to user adoption. Additional development time is multiplied many times over by maintenance time. Increased training to use, customer service support, returns and non-renewals. Jared Spool suggests forming all requirements in the form of testable hypotheses: https://articles.uie.com/requirements_gathering/
- Should have at least 45 minutes by this slide
- So, what does it take to build the Right It? Looking at your business and your company through fresh eyes.
- So, what does it take to build the Right It? Looking at your business and your company through fresh eyes.
- When we set about defining user requirements, we usually jump to asking them to confirm their interest in the features we think or hope that they want, rather than taking a step back and trying to understand their Needs Environment Expectations Obstacles to trying something new Jared Spool suggests forming all requirements in the form of testable hypotheses: https://articles.uie.com/requirements_gathering/ Do you validate requirements with users? Surveys, interviews, card sorts? Do any of you do routine rolling studies or iterative usability testing? What do you do?
- What stands out for you about the conversation so far? Any insights or tools you can use?
- Questions? Ask for feedback Offer up contact info.
- Questions? Ask for feedback Offer up contact info.