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]”
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!
Each strategic project is a set of related user stories – Liz Rice, MindTheProduct
The lively discussion continues around exactly how strategic is Agile if you constantly run short Sprints. Doesn’t it take longer to be strategic?
Actually no…The two concepts (Agile & Strategic) are not mutually exclusive! I read a very interesting article this weekend by Liz Rice who outlines exactly HOW to do this. She’s keen on being realistic and keeping on track.
Liz advocates using a roadmap and planning to prioritize User Stories needed to build the MVP, keeping in mind that it is best to not bog down in details. Plan for the predictable things and get buy-in from your development teams. We all know priorties can and will change, that’s what Agile does so well. Don’t sweat the small stuff but remember if you don’t consciously integrate critical MVP “must have” features into the Quarterly Plan you’ll be forever dealing only with short-term and “urgent” requests.
And that’s no way to develop world class software.
Marketing, sales, accounting, support – how do the rest of us handle the cadence of releases from fast, efficient Agile development teams?
I captured a high level summary of product professionals’ discussions at a recent event in Atlanta, called the Agile Affect. The panel of four and moderator all had significant experience in both waterfall and Agile. The audience was no different. Bottomline, if your product organization builds to MVP, so should your stakeholders.
- You don’t have to be a developer or a product manager to use Agile methods in your craft. That being said, it’s not one-size fits all.
- If you are in marketing, sales, support or operations in a company the embraces Agile in product development, it’s best practice to modify Agile methods to build your own cadence.
- There should be a balance between major and minor releases to product. It’s fine to deploy every month yet hold a marketing launch every quarter or to the time-frame which best fits your market.
- Whatever you do, do not overwhelm sales or your markets with over communication. Here’s that word again – balance the need for iterative product development with the need for clear product benefit messages.
- Every stakeholder department can create repeatable processes for sharing market context and messaging. All can prioritize demands based on the most urgent needs.
- Operations and support really, really need to be engaged, at the hip, with the Agile development teams.
ProductCamp Atlanta 2012 is next Saturday 18 August. I would bet this discussion continues there as well.
Would like very much to hear your stories about creating the Agile Affect in your company.
Ever wonder why there’s the saying “hindsight is 20/20”- it’s because psychologists have proven our bias towards thinking outcomes must have turned out the way they did and we are convinced we knew it all along .
So what’s the problem?
Because of this bias we may not be learning from our fumbles and that’s a shame. See here:
The hindsight bias is our tendency towards thinking that things must have turned out the way they actually have. The hindsight bias can be a problem when it stops us learning from our mistakes. If the entrepreneurs knew how biased their estimates of success were, would they have done things differently? … how will they learn to consider alternatives? – Jeremy Dean, @PsyBlog
What’s the solution?
Honestly look at our judgements and provide/think of alternative ways things could have turned out. I think Daily Scrums and Retrospectives help Agile teams see how differently things could done if teams were not wrapped up in hindsight BLINDness.
What do you think? Is hindsight always 20/20 as the saying goes?
Do you think hindsight bias is always unproductive and negative? How do Agile teams guard against bias? Is it just “per unusual” in creating product and we who design and create just have to get on with it?
The main thing
is keeping the main thing
the main thing
A product launch begins when *everyone* involved can say what truly makes your product outstanding and awesome.
No, that’s not a typo.
I didn’t mean “product launch ends” – because if you begin developing product without clarity on this, no telling when you’ll launch. Or what will launch. Or who you should be launching to…