Tagging: Agile
-
An Introduction to Modern Product Discovery Practices
@ttorres’s product discovery keynote from Productized Conference 2016.
Goal: learn fast
(Output » Outcome)
- Are we meeting stakeholder needs?
- Can customers us it?
- Do customers want a solution?
- Are we solving a problem customers care about?
- Are we droving toward a desired outcome?
The Opportunity Solution Tree: Desired Outcome (OKR) » Opportunity (JTBD/product strategy) » Solution » Experiment
-
What big corporates often get wrong about Service Design
Fantastic article by Douglas M. Smith about the 5 mistakes big corps make with Service Design.
-
The Horizon of Inquiry – To find time for research, don’t fight the flow—fit into it
@mulegirl shares a model of fitting research into the flow of continuous work.
The key is not to optimize for your comfort, but to rethink how research integrates with the rest of your product work or other business decisions.
Continuous learning is no different from continuous shipping. Big releases take longer and big questions do too. We’re just used to thinking of the endpoint of research as a report rather than a decision—an artifact rather than an action.
Generative: What problem might we solve? Descriptive: What is happening currently/happened historically? Evaluative: How well is our solution working? Causal: Why is [x] happening/Why did [x] happen?
The lower the overhead of identifying research questions, planning the study, and recruiting participants (if necessary) the more realistic it will be to accommodate interviews, competitive research, or usability testing within a development cycle. Develop good habits and document the steps.
You can try timeboxing small research projects. Say for example “What can we learn about [x] by the end of the day?” We do this all the time in our daily lives when planning vacations or making major purchases. It’s the exact same process with a bit more rigor and collaboration.
Every organization has cycles, whether it’s the school year, the fundraising calendar, quarterly reporting, or a continuous series of iterative product development sprints. You can’t fight time, so work with it. When you think a bit ahead and map your questions onto your calendar, you’ll soon hit your stride of continuous learning.
-
Five dysfunctions of ‘democratised’ research. Part 1 – Speed trumps validity
@leisa’s calls out the tradeoffs of compromising speed with validity, the first of five research dysfunctions.
It’s not a coincidence that people usually start with ‘build’ and rushing to MVP when talking about the ‘learn, build, measure’ cycle.
What do we mean by validity? In the simplest terms, it is the measure of how well our research understands what we intend for it to understand.
[…] if the work that results from your research findings is going to take more than one person more than a week to implement, it might be worth increasing the robustness of your research methodology to increase confidence that this effort is well spent.
-
Here’s what to do when user research doesn’t fit in a sprint
@jseiden’s thoughts on Agile and research.
-
Running in Circles
@rjs sheds light on the uphill struggles and responsibilities of protecting the agile team.
-
How to Stop UX Research being a Blocker
@ben_ralph has some interesting ideas on how research can co-exist within agile teams with foundational and directional research.