There’s some handy tips in this article – 10 best practices for usability testing with agile teams
3 simple things you can do
- Frame the work as a learning problem, not an execution problem. Make explicit that there is enormous uncertainty and interdependence ahead.
2. Acknowledge your own fallibility. Say simple things like “I may have missed something. Your input is important”.
3. Model curiosity. Ask a lot of questions. This will create necessity for people speaking up.
Harvard Business School professor Amy Edmondson
Things that contribute to poor collaboration
- Excluded from planning
- Lack of a decision-maker
- Inconsistent expectations
- Oversimplification e.g. “just get a bunch of smart people into a room”.
Not a lack of tools, like Skype or Sharepoint. Don’t prioritise software tools over management/behaviour tools.
Things that contribute to good collaboration
- Establish a communications plan. “Let’s check in every morning at 9am” “when you’ve got something to show me, ping me on slack … “
- Provide a rationale for decision – make sure you have a good reason for doing the things you do on a project.
- Define roles and responsibilities – “I’m the design lead so anything to do with budgets or timelines falls to me”. “There are a bunch of tasks. Let’s define the tasks and assign responsibilities (and throw out titles until they tasks are done).”
- Set expectations about performance. “Here’s what I need you to be able to do”. “I’m expecting to see a handful of mock-ups by the end of the week”.
- Communicate progress. “I can’t manage what I don’t know”.
- Be honest about your approach, output and performance. “How can I be a better contributor next time?”
This technique has been discussed a number of different times.
A discussion today about the technique skewed towards favourable, but with the caveat that you need to be sure you have included representative users/customers.
If you miss that first consideration, you may be heading off on the wrong track despite your best intentions …
“However, even with increased awareness of “co-design” and “social innovation,” it can understandably feel risky for governments and foundations to invest in new approaches promising yet-to-be-discovered outputs.”
Oh man. This is exactly the point I was trying to make at that session with design academics several years ago. No one was particularly ready to engage with the conversation I was trying to start.
Personally, this is my frustration with academia. So much valuable insight and research, but an unwillingness to engage with the more pragmatic conversations.
I’ve always admired TACSI’s ability to work across both spaces and get good and admirable stuff done. Reading this article further reinforces my admiration.
“It’s human nature to be biased. It’s human nature to fall in love with those ideas … for me, the thing that will make us more successful as a company … is when we get a lot of great ideas but can quickly synthesize them and figure out the ones that are most important and impactful. And really have a culture where we are willing to look objectively at the situation and the needs and make investment decisions that will give us the best return on those investments.”
This is worth watching if you work in product.
Lots of talk about the importance of discovery – both qualitative and quantitative.
And the importance of identify impact (measurable impact) of a change or new feature.
The challenges of working in a larger organisation, in enterprise software, was a useful perspective. A lot of the stuff written for/by startup people, about product, is great. Just great. But it’s a long way from moving something through a larger company that has established norms, and so many stakeholders.