An Hypothesis is Really a Prototype [Series 4/5]

Agile as the Innovator

Thought bytes

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

 

Innovation by Immersion [Series 3/5]

 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]”

If a Customer Asks “Can You Hear Me?” Will Anyone Hear?

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.

Customer Development

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!

Strategic MVP and Iterations

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.

Great Scott – We’re Agile but Where’s the Rest of the Company?

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.

Cheers!

 

The Hindsight Bias – Be Agile – Learn and Re-Learn

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?

Cheers!

Essence of the Main Thing

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…

Cheers!

User Stories Help Build Sales’ Stuff

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”

It’s Not Small Change (Series 4 of 4)

Part 4 of Agile Product Marketing Series:

  1. Product Marketing Becomes Agile
  2. What’s a Product Marketer Doing with a Roadmap?
  3. The Launch Queen Speaks
  4. It’s Not Small Change

This is the last of a series written to help Agile and B2B Marketing teams understand each other’s conversations and methods.  Previously, we discussed how Agile practices can integrate within traditional product launch management and commercialization.

Change

It’s the people- the human element– that we’re talking about.   Continue reading “It’s Not Small Change (Series 4 of 4)”

Product Marketing Becomes Agile (Series 1 of 4)

Part 1 of Agile Product Marketing Series:

  1. Product Marketing Becomes Agile
  2. What’s a Product Marketer Doing with a Roadmap?
  3. The Launch Queen Speaks
  4. It’s Not Small Change

This post is the first in a series designed to help Agile and B2B Marketing teams understand each other’s conversations and methods.

Attention Scrum Master or Product Owner!

Are you working with a Marketing Team and hoping they don’t think Agile practices mean another form for Yoga? Actually, we marketers know about Agile and are cautiously curious and optimistic.

You can be absolutely sure that marketers working with Agile development teams wonder how they’ll be able to Sprint faster, while shaping, communicating and testing the product’s market message, value prop – in time for successful commercialization.

Provide a Bridge

Invite your PMM to join in the Stand-up. Share your Backlogs. Collaborate.  Marketers must be plugged into product information as real-time as possible in order to understand the product as it is now defined. With your help, we’ll do a much better job working our magic. Continue reading “Product Marketing Becomes Agile (Series 1 of 4)”