Agile as the Innovator
Don’t think research is a phase, it is really ongoing. Prototyping is the way you learn. You learn so much by watching how people learn. It’s OK if the prototype is really rough.
Rapid prototyping your guesses* is an iterative process. You learn just enough to feed into building a better prototype. Then you go out and learn more, build again.
Launching is validating how much more solving is needed. If not solving the problem, re-calibrate.
Service design seems similar to product design – but it is harder to prototype an “experience.”
Product design creates an experience. ID the real issues.
Key is have a clear objective of what you are trying to find out.
Think about the smallest thing you need to do to get the most learning – throughout the entire life-cycle.
Storyboards! Stories describe a type of interaction.
Always design for people.
* My note: a simple word for hypothesis?
Next up: Outside in Perspective
Experience is the Message
People have experiences about product, products don’t have experiences. – Marcelo Marer, Chief Creative Director, Intel Media
What sells well in the U.S. many not be a benefit to anyone elsewhere. If you sell globally, it’s critical to design products for the new markets you plan to enter. Doing so requires research and an honest/thorough analysis of the information you have collected.
User Stories and User Personas
In the previous blog, the product teams hypothesized their customers and prospects need to collaborate – on demand, from anywhere – with their partners and other growers, in order to be more productive and to reduce risk. Continue reading “Innovation by Immersion [Series 3/5]”
Customer Driven Innovation: A Global Perspective
Changing iron by using the cloud
Growers (Matt rarely called his customers “farmers”) are a uniquely tenacious and optimistic group. They have to be risk takers too, so many out-of-their-control environmental factors impact outcomes. You might never guess that this group is well set to innovate/change how they farm.
The head of Product Management explained that today’s growers, in order to feed the many billion of us, must find ways to limit their risk and increase their yield. They’ve already teased out most of their farming costs from fuel (which impacts feed, fertilizer and other necessary items on the farm). More was needed to be done – there are hungry people to feed.
Continue reading “From Iron to Cloud – Customer Driven Innovation [Series 2/5]”
When we stopped doing customer development, we stopped learning. @LeanCircle
To some, I’m a Suit. The only Development I ever did included using Lotus 1-2-3’s macro language to build applications and a business. I know only a few things about building successful applications for customers; how – I totally get customer development.
These things are clear to me:
- You don’t build stuff (applications, databases, software, apps, websites) for yourself. You build these things for your customer.
- Get out of the building. It’s the only way to make sure you aren’t just hearing yourself/ talking to yourself.
- Few technologies fail because they’re not good stuff. Instead, they fail because they don’t solve customers’ problems.
- You are not your customer, so you don’t know what their problems are.
- Get out of the building. It’s the only way to make sure you aren’t building cool stuff that only you can love.
These are awesome and interesting words joined together. It doesn’t mean go out and speak with as many customers as possible. That’s nuts, instead go Lean. Speak with as many customers as possible who help your teams build MVP. If you cannot find any customers…well maybe this isn’t a problem to solve. Just saying!
I’ve been thinking how product development, product marketing and sales teams should be joined at the hip.
Seems only natural since we build stuff (tools, live product demos, APPS, websites, etc) to support sales’ efforts converting leads to customers. One thing I have noticed is that not everyone in this triad is on the same page regarding “done” or what is to “be done” when it comes to creating sales tools. That’s a problem. Continue reading “User Stories Help Build Sales’ Stuff”
I recently attended an interesting and interactive NPD learning event about using “Personas” to define product features. Very much like User Stories but made using ethnographic (field research) methods. Personas tell their story in terms of goals, the “why” and “how” of what they do. It’s not at all easy to be good at defining unique and evidence based personas, but the outcome is worth the effort.
The speakers introduced our personas by name, provided us Post-it notes, Sharpies and paper iPads. We broke into teams of 6-7. Our goal: to create a wireframe of a Tablet App front page appealing to the travel requirements of our assigned persona. In about 20 minutes, we were ready to showcase our work.
Here’s the interesting point>>throughout the designing, the teams remained focused on the person in the persona. Features, elements, text, flow were all designed with the persona’s needs top of mind. It was as if the persona was there with the team. There was a shared understanding of needs within the context of the persona’s world, and the outcomes were all awesome (and quite different).
I am a believer! By including personalities and behaviors of the buyer, early and often, into product decisions, teams will make great product design decisions.
Priority is to Satisfy the Customer.