Month: December 2007

Slogging through the details? Get Agile.

So – the strategy is clear, the thinking is exciting, the opportunities immense. What’s left now is to get it done.

And its not all easy, and its not all fun. So how do you slog through the minutia? These details that can be painful to document are so important to success, so – what’s the best way to approach them. In my case, I’m working on a Product Requirements Doc for a client. (I’ll do anything in the name of a great outcome). The outlines of the product are clear and everyone’s excited about the product direction. And still – getting every detail on paper is taking longer than it should, and delivering less value than it should.

The answer here depends on the circumstances, and who you are, and what you’re trying to achieve. But I think the best weapon is a buddy. Have someone to walk through the details with, and instead of a boring, painful, process, you suddenly have a vibrant conversation.

Who’s your buddy? Well – in the case of a Product Requirements Document your best allies are Design and Engineering. They each bring great insight to the table, and its essential to be in lock step with them. This small step is, in fact the first step toward an Agile methodology.

The Agile process is one of the most productive, efficient and altogether engaging team structures. In this process, design, product management and engineering get together, define the general outline of the product, and take a deep dive on a piece of it. Then, engineering goes and builds that piece, and design and product management go deep on the next piece. Then engineering gets involved again, and so it goes. Iterating, learning, iterating and learning. I’m a huge fan of this process, and most engineers I know like it too.

The key tools of the process are collaborative communication, trust and respect. People need to be on their toes and know you are too. The result is usually a highly aligned team, with a high degree of collegiality, and a killer record for getting things accomplished. People work in parallel, but not in isolation. Engineering isn’t left waiting while product management figures stuff out, and product management isn’t left with the huge burden of arranging every detail on a platter for

There are pros and cons to this method. The pros is that it can dramatically reduce schedule risk, gets all the best minds in synch, and can be very responsive to changes in requirements and learning. The cons, is that if you must have extensive face time. If part of your team is half way around the world, it can be extremely difficult to achieve this level of communication. I’ve not managed it yet myself. But, I’m sure that if I could, the productivity of the team would soar, as would morale.

Has anybody out there been successful with Agile across continents?

But Agile is not just for Engineers. Agile tactics are very well used in design, marketing and any other part of the business where cross-functional collaboration is key, and parallelism is important. There are great books on the subject, but I think the best way to learn about the method is to chat with people using it, or even better, attend some sessions. I can hook you up with some, if you like. Just ping me at deb at productfour dot com.

Advertisements

A Laptop and a Network: The Technoliday Party

Here’s a bit of interesting news: There’s a vibrant community of young, fiercely ambitious, smart, friendly New Media super savvy professionals in the Washington D.C. area. And most of them will be at the Technoliday party next week.

The party is a fundraiser to support One Laptop Per Child. Tickets are $50, including food, booze, and $20 toward a laptop. For every $200 raised, one child in a third world country will get a laptop – a ticket to education and enterprise.

This is certain to be a great opportunity to meet people, have a good time, and do good all at once.

I’ll be there, and I would be delighted if you were too.

How do you know when you’ve got the right value proposition?

Last month, I wrote a post about the Value of a Value Proposition .

It must be a useful subject, because almost all of my search engine traffic comes to this one post. Again today I found myself talking about the value proposition with a client. Its the most precious thing you have – its what is valuable about your product or company. And it isn’t always easy to formulate or agree on.

Here’s some hints about the process:

– If your value proposition takes two paragraphs to describe, you aren’t done yet.

– If you don’t have any customers or potential customers who say – yes – I have that issue, I need that solution, then you aren’t done yet.

– If you need to rehearse the sentence to get it out of your mouth properly – you aren’t done yet.

If everyone in your company or team, when asked, will spontaneously say something more or less identical – you’re getting darn close.

Now – just because you aren’t done yet, doesn’t mean you don’t have something really special. What it does mean is that you haven’t yet made that connection between whatever brilliant insight you have and your customers world view. So what can you do about this?

1. Talk talk talk talk and then listen, listen, listen, listen.

Tell as many people as will stand still about your idea. You’ll probably go through a phase where you’ll get one of two responses:

– blank faces

– one or two people (who probably like you a lot for whatever reason) will tell you that you are a genius.

This is not a good phase. And I’ve spent some quality time here. The best thing to do here is to try to get those blank faced people to talk more. And, of course those people who think you’re a genius too – but its more important to be able to explain it to the blank faces. Ask them (if they haven’t turned away yet) to help you by explaining back to you what they think you might be saying. And listen. Don’t dismiss – even if you think they have no vision. They may have no vision – but neither will 99.9% of your future customers and investors. You really do need to be able to explain it.

Another technique – draw a chart. Make a picture of what you think you’re offering. Now make a completely different chart to describe the same thing. In other words try to look at the problem in lots of different ways, get creative about seeing it from other people’s perspectives. Try a usage table – a tool I use quite a bit – one column is a list of possible users, the second column is the value they’ll get out of the product, the third are the features that support this. Once you’ve nailed your value proposition, this is also a nice tool for the development of your Product Requirements.

Focus groups. If you have the ability, try a focus group. I’ve seen the value proposition fall out of the most unlikely mouths while standing behind a one way mirror, after we’d worked on it for months. A different, objective perspective can be very illuminating.

Online surveys. Once you think you’ve got it. Consider it an hypothesis. Use an online survey to test your hypothesis. Online surveys are cheap and easy. The hard work is in formulating the right questions, developing your email list (not all that hard, if you know your audience) and most importantly, listening to the results – especially if they are not what you predicted.

Once you have the right value proposition, it will feel right. It will be easy to describe. People will nod their heads. Survey results will start making sense. The product, design, marketing, positioning, everything will begin to fall in place, and all thats left is to execute flawlessly.

Good news – I think my client’s got it. Its short, its sweet, he and the team can repeat it easily, and people get it. Yipee! Now to that flawless execution….