The culture of innovation, the impetus of the maker movement is a culture of doing and experimenting. It’s OK to start small. If you’re in the middle of a startup, you’re too busy to drop everything and learn lots of new stuff. If you’re in an enterprise, not everything’s going to change at once.
Here are a few of the (very reasonable) questions I see:
‘How do I get organizational buy in?’
‘How do I get budget?’
‘When should I start?’
‘How do I change the existing processes?’
These are good questions and they matter, but probably not at the beginning. The most important thing is to find small, tactical opportunities to practice and to use those to accumulate wins. It takes some skill to recognize those and apply the right methods, but for someone who’s read and tinkered with the Venture Design material, a learner in my Coursera class on agile, or one of my students at Darden, that’s not a problem.
In my work with clients, I rarely start from the point I’d naturally recommend (creating personas). A lot of the time, we start with agile user stories. The team doesn’t want to ‘go backward’ and create personas to see if the problems they’re solving are really important. Sometimes, they’re absolutely right- there’s enough observation in place to know the problem is important, and even that the solution is relevant. We tune the stories, move ahead, and the feature is a hit with users. Sometimes, it’s clear that the stories are on a shaky foundation and we trace back to assumptions and testing motivation, and sometimes from there back to problem scenarios. It depends, but the point is you can start anywhere and still majorly improve your outcomes.
This material isn’t hard to understand- it’s hard to practice. That’s where you really have to push yourself and, yes, you’ll probably have to invest extra time in your work to work out the kinks and start practicing.
I’ll close with a few examples of things I have seen students and individual clients do in the middle of an existing work stream:
- Ask the right kind of questions about a user story: Does it have a testable reward? How would we know if a usability test is successful?
- Draft a storyboard about a user story you want to understand better and {bring it to a meeting, photograph it and email it, attach it to a ticket}.
- :: Lay out assumptions about motivation to clarify someone’s thinking behind a given feature request.
- :: Create a mock-up/prototype with Balsamiq to clarify a user story
- :: Pull comp’s and patterns to ask questions about how a feature might work and how you might approach it.
- :: Design a quick usability test with your prototype and run it w/ whatever subject you can lay your hands on.
If you were waiting, I hope you’ll go ahead and push yourself to practice- even if it’s small. Post a comment below and share how it went for you!
