Takeaways from Márcio Machado’s Beer and UX presentation.
Márcio Machado believes that product discovery is essential to great design, and we agree. When he joined Beer and UX to deliver a talk on product discovery and why it is so important, Márcio began by clarifying that discovery is not asking your boss, or the highest paid person in the room, what they want the product team to build. He went on to explain that product discovery — when done well — is a continuously measured and collaborative exercise that helps us understand a problem and explore hypotheses to inform delivery towards desirable outcomes.
As a design and technology practitioner with more than 20 years of experience, Márcio shared seemingly endless insights on the value of product discovery, with the aim of helping attendees promote and evangelize discovery within their organizations. Currently Márcio is the Lead UX Strategist at Headstart, a recruiting software company working to help talent teams fight discrimination and engage diverse in their hiring processes.
While we’re sharing just four of our favorite takeaways here, we’ve uploaded a recording of Márcio talk to our YouTube channel for those who missed it.
Discovery is not for testing or validating existing ideas.
Exploring a hypothesis should be at the core of any discovery endeavour. Discovery, Márcio explained is about solving problems, not validating proposed solutions. Exploration is crucial to the discovery process. Too often, he has been approached by stakeholders looking to validate their ideas with discovery, something that Márcio feels biases the process. “You go from discovery to ideas, not ideas to discovery,” he explained. Instead, the process should be approached with enquiry and observation. Our goal as design practitioners should be to work through a research problem and gain strategic alignment within your team.
Inputs he reminded us can be gathered in many different forms, whether its user interviews, support call monitoring, ad hoc, feedback from staff, the inputs should be collected, aggregated, cleaned, split, clarified, and normalized. “If you can’t interview, observe. If you can’t observe, do some desk research,” he added. Embracing exploration, taking small steps, deploying, and getting feedback from users or analytics you will create opportunities to learn.
When you can’t do the kind of research that needs to be done, bet on experimentation and try to limit your assumptions. The output however, should not be a report. Instead he encouraged the audience to tell a story and make their work easy to digest and understand with useful deliverables like problem statements, personas, or journey maps.
Márcio noted that 60% of startups fail. While providing a list of all the common reasons startups are said to fail, he noted three in particular that could be addressed with discovery: the absence of market need, being user un-friendly, and ignoring customers. The discovery process pushes product teams to move from delivering a solution that is satisfactory to delivering a solution that is delightful.
Discovery also helps teams mitigate other risks by creating space for critical reflection. It is during the discovery process that teams can ask themselves and explore concepts like ethics. Thinking critically and holistically from the onset promotes longevity.
Discovery is a team sport.
When it comes to discovery, collaboration is not just a nice to have, it’s mandatory. Furthermore, it must be multidisciplinary and empowering. Evangelizing is key, Márcio explained. Similar to David Silva, who presented on design leadership, we can build excitement about discovery by letting people see behind the curtain. One simple way to demystify the work is to invite people from other teams to observe whenever research is being conducted. Another tactic Márcio shared was creating a Slack channel called “UX researcher for a day” and sharing insights from the discovery process as you uncover them.
Putting it bluntly, Márcio stated that without collaboration, outsourced discovery projects or internal innovation labs are good for entertainment and little else. Even when working as part of a vendor or agency team, the discovery process must be collaborative. This means including the delivery team. Too often, discovery teams are treated as separate from the delivery team and involve only project managers and UX designers. Márcio reminded us that everybody from developers, to business analysts should be involved in the discovery process.
As we work to ensure our teams are multidisciplinary, Márcio pointed out that sometimes the language of design can be alienating, leaving stakeholders feeling like it’s not for them. The Jobs to be done framework, he noted, is one that consistently resonates well across organizations. He went on to recommend Jim Kalbach’s book the Jobs To Be Done Playbook book, which is a great resource for teams.
Discovery can (and should) be measured.
In fact, you must measure. In the absence of a discovery measurement framework that resonated with them, Márcio and his team created a framework called “Discovery OS” to evaluate their work against a rubric. With this framework, he advises teams to hone in on five metrics, each with their own set of questions:
Is our discovery process collaborative?
Is the work being done by one person or by everyone?
Is the process ad-hoc or are there guidelines for the team to follow?
Are the responsibilities shared or is there a single leader for the entire process?
Is our discovery outcome-focused?
Is Support just fixing issues, or are we collecting context for the Support team?
Are we visiting and interacting with customers or just listening to survey responses?
Is it only the project manager and UX designer that are collecting feedback, or is everybody collecting feedback?
Are we doing lean [expletive] or are we running user research?
Do we celebrate features or do we celebrate outcomes?
Do we gather design ideas or do we gather knowledge on practice?
Is our discovery process testable?
Is the MVP treated a sub product or was the MVP created for us to learn?
Are we prototyping or are we “pretotyping?”
Are we producing only high-fidelity prototypes or are we also producing low-fidelity prototypes?
Do we only work in a production environment or do we also working in staging?
Have we set up analytics?
Do we hate being wrong, or do we celebrate wrong ideas?
Is our discovery work measurable?
Do our research questions stay the same, or do they change?
Are we just optimizing, or are we actually discovering?
Can our goals be quantified?
Are we self measuring, or is there no meta evaluation?
Customer data (later) vs. field data (in the moment)?
Secondary research vs. primary research?
Is our discovery process continuous?
Are we doing discovery only once in a while or is it happening regularly?
Are we taking a short or long view to the experience vision?
Do we have sporadic access to users or regular access to users?
In addition to the questions above, the Discovery OS framework encourages Márcio’s team to ask themselves another very important question: “based on our current context, how can we improve our collaboration or outcomes?"
Watch Márcio’s presentation
We are very grateful to have been joined by Márcio for this incredibly talk. If you would like to see the presentation and Márcio’s slides, you can find both on our YouTube channel.
Beer and UX is a Meetup group with more than 1,800 members. Hosted by Neuron, this community of design enthusiasts meets regularly to hear from industry professionals, debate, and collaborate.
コメント