moved to wordpress

Just so you know - this blog has moved.
Please catch up at productfour.wordpress.com
Thanks, and sorry for the hassle.

Well, Wow. That was fun.
D.C. startup weekend is sort of like an entrepreneurial jam session with the goal of launching something viable-ish by the end of the weekend.

About 70 people showed up, from about every discipline involved in tech startups. Many of them were way good at their craft, and they were all extremely pleasant to be hanging out and working with.

And yes - we launched a product: Hola Neighbor

It's a tool for neighborhoods to self-identify, connect and communicate. I've already started setting it up for my new neighborhood, and I expect my neighbors to like it enough to sign up (it is free).

Startup weekend is as interesting as an anthropological study as it is anything else, however. Watch how teams and leaders emerge. Watch how conflict is resolved in an environment where it is very low risk for everyone, mostly a-political, and where everyone has at least one shared goal, and minimal hidden agendas. A very collegial environment, where all we have to gain is some fun and a little local reputation, and all we have to lose is some time.

Process. Process matters. In this case - trying to launch a biz in 24 hours, there was a LOT of parallelism going on - UI, dev, marketing and business going off and doing things in parallel, making assumptions about what the product was and what others were thinking. The amazing thing, is that this pretty much worked. Every once in a while we synched, found out the disconnects, argued, resolved, and moved on.

More process - we set milestones, and tracked progress more or less hourly. The meetings were brief, but effective catchups. Agile-ish. Some of what was useful about this was that everyone knew the process, it was easy to comply with, and not too formal.

Critique of my own performance. So, there are many aspects to getting products up that are deeply interesting to me. Fundamentally, I'm about the value proposition - making sure that the user value of the product maps to what users care about, and that the business value prop is also real. And since there was no product management group, I sort of floated between User Exp, Marketing, and Biz Dev. Each team was self-formed and populated by truly grand people. I feel I contributed to the clarification and prioritization of issues in each group. But had I to do it again, I'd pick one and stick. I feel I let each team down by drifting. Either that, or I need to declare myself as philosophical pollinator - making sure all the groups had similar thinking on key issues.

One contribution I might have made if I stuck to one team is the keep it simple one - I think the product started simple: 3 key features, and even within the scope of 36 hours, feature creeped itself out of clarity and quick build-ability. But hey, the whole point was to have a creative weekend, so maybe that feature jam was a real part of the pleasure of being there for some.

In any case, Peter Corbett, Andrew Hyde, Jared, Matthew, Victoria, Micah and 60 others are people who I will remember fondly, especially when I catch up with my neighbors at Hola Neighbor. And I very much hope to work with many of them again sometime. I'm even thinking of going to Startup Weekend San Francisco...

So, now we've found the problem...

I recently posted about the trouble seeking process (The Virtues of Looking for Trouble). So, I’ve been asked the question - what do you do with trouble when you find it. Well, in short, the goal is to minimize risk, and maximize opportunity.

How. Well - first, as I said before, its imperative that you always have your ears open for trouble, and make it a regular activity to discuss it with the team, and whatever management you have. Some very successful saves have happened when companies went to their users, admitted the problem, and proved they were solving it in the right way for their customers. This is a great strategy when the problem is user-facing (bad press, low customer sat, big glitch, etc). But in general:

1. Keep blame out of it.

Even if someone really screwed up, there’s time to deal with that later. Blame will not help solve the problem, and blame will make it much, much, much harder to discuss problems productively. No one will bring up bad news if they fear they’re going to get slammed. Most of the time, assuming that you have a good team, the blame will be that we work fast, blazing paths through the unknown - we’re paid to innovate - that means we just don’t always know in advance how things will play out. So - respect and trust. (And if you do have a bad egg - deal with that quietly, and make sure its about skills, talent, match, etc and not about “this went wrong and its your fault”. But that’s a different subject)

So back to dealing.

2. How bad is it?

Is there general agreement that if this problem is not managed, the launch, the schedule, the user adoption, the business model or other critical success metric is in clear peril? If so, all due attention should be These should be at the top of the agenda, and made as visible within the organization as possible. Make time to collect relevant info, to brainstorm solutions and be sure to clarify the decisions that must be made, and their likely outcomes.

3. Verify and characterize the problem.

Once the problem is on the table - get general input on it, then make it someone’s responsibility to map out the size and shape of the problem. Is it a lack of information? Is it a technology glitch? A new competitor? A design flaw? A resource issue? What are the ramifications? Best, worst case scenarios? Is there a critical decision point, or is this something we can just watch.

5. Identify key decision factors: (ie if this outside event does not occur by this date, then we’ll… ), if this metric hits this mark, then…, if this study returns this result, then….. If the blah blah group (or partner, or whatever) can’t deliver x, by y, then…

4. Decide on a course of action: Solve, remediate or watch.

Some problems can’t be solved, but you can keep them from undermining all your efforts just by tracking them, and responding when and how you can - is it positioning, PR, expectations setting on the schedule, feature-rejiggering, getting new partners, etc. A team that can sit down and really hash out problems will get to the “aha” moments much faster. A team that is looking for, and dealing with trouble effectively is going to make it to the goal line faster, and score bigger.

Moreover, many problems, found and managed early, will make your project, product or campaign much much better than you might imagined. Stay tuned for “How canceling a project won over our users”.

Please don’t break the back button.

Ajax, Flash and Flex have brought real interactivity to the internet. The UIs they create are visually richer, and, unlike html, offer great flexibility of interaction design nearly equal to what can be done on the desktop. However, these apps still run within a browser. Many of these new apps, in reaching forward with these new tools, have, unfortunately thrown a bit of the baby out with the bathwater. They break the best thing about web browsers - the dead simple and universally functional navigation scheme of the back and forward button. That means that when you hit the back button, you sometimes end up somewhere at best surprising, but more often, annoying.

This problem can be avoided. The engineers I worked with at Adobe came up with a few tricks to ensure that the boring, but beautiful forward and back buttons still work. Please follow their example. Don’t break the back button.

The Virtues of Looking for Trouble

Rarely do products fail for reasons that were not known and predicted by at least someone on the team. Frequently we find that these concerns were glossed over because, for a variety of (often compelling) reasons, bad news was not welcome at the meeting.

How does one seek out trouble? The short answer is that anyplace there is vagueness, worry, or unexpected or disconfirming information, it should be a high priority to check it out. But often this does not happen.

What are the reasons? There are 3 main reasons, and many minor ones.

Here are the biggies:

1. Passionate belief in the product such that disconfirming information is ignored or explained away without serious consideration. This is a common reaction to market research results that do not meet expectations.

2. Management pressure. There are organizations (believe it or not!) where the culture simply does not admit bad news. Blame is rampant and fierce, and no reasonable person wants to be hit with it.

3. The need for speed - sometimes there’s just so much going on that the team just puts its concerns on the back burner to be dealt with “eventually”.

The remedies

1. Sophistication

Its important that the team be infused with an appreciation of the value of trouble seeking. That trouble managed eary can make a product better, faster and more profitable. It supports and maximizes success. Trouble managed late is simply firefighting. It is beating off failure rather than actively pursuing success.

2. Humility

Sometimes we all make mistakes. Accept it as inevitable, accept mistakes as part of a creative, fast moving, accept it as a virtue. Learn that the wisest and smartest and most successful person is the one who is able to coolly evaluate their current status in order to go further.

3. Shared Trust and Respect

A team that has a deep, shared sense of trust and respect will find it easy to bring problems to the table and get great solutions. Teams that lack these traits make it awkward to bring problems into focus, or admit (gasp!) mistakes, or make the price of this a big pile of blame. So problems remain hidden.
When you believe your team is good, dedicated and focused, you know that they bring problems to the table to get the fastest, smartest solution that the full team can deliver. A good team rewards bad news found early.

The Value of a Value Proposition

My current project is working with a very early stage startup. They, like all new startups, are working very hard to get what they want and need - a great product, excited users, some press coverage, and investors.

We’ve been discussing how to best define, refine and articulate their unique value proposition, and some very interesting (to me at least) themes emerged from the conversation. While there is considerable and unique value they are building, they, like almost every product team, are struggling a little to find the best way to articulate it. And, not being traditional product managers, they asked a simple and great question: Do we really need a value proposition?

Some team members went on to say things like “After all, the bar is so low to trying free online products, all there needs to be is the slightest hint that it could be useful. And besides, we can’t possibly predict all the values the product will have for all its users”.

At first, all I could think was “oh, brother.” My next thoughts went down two roads. The first was a list of the reasons you do need a well articulated value proposition (is it just a sacred cow?). I’ll share these down the page a bit.

But the other thought train went this way: we are in a phase where the power of emergent behavior (the wisdom of crowds) is newly important and useful online. One of the key values that this team is actually expressing, is that in addition to creating specific new value, they are enabling their users to find and create the value they want, and to use the product as a platform to get done what they want to get done. They are designing this product to allow its users to influence its value and its future.

That is terrifically cool, current and powerful.

Having said that, there are still some pretty good reasons for articulating your value proposition, even if part of your value proposition is dynamic.

A value proposition defines and describes WHAT a thing does and for WHOM.

So - why is this useful.

1. A value proposition helps design the product.

Once you are clear on what your product does, and for whom, your choice of features, navigation, look and feel are much easier, because you have clear criteria to evaluate your choices. (Anybody ever work on a product that did everything for everyone? Was it fun?)

2. A value proposition helps market the product.

A value proposition is not the same thing as a tag line, but its certainly the first step. More over, the what and for whom identifies your target market. (obviously articulating the value proposition is not necessarily the first or only place you’ll be discussing the target market, but it helps reinforce the very deep relationship between the target and the product). Knowing your target is, of course, the first and most important step in finding, targeting, messaging recruiting and building relationships with those people.

3. It helps investors/management/partners get excited.

Hard to get excited about/support/invest in a product where only a couple of passionate guys “get” it.

4. It doesn’t matter how low the barrier is to trying your product, you still need folks to be motivated enough to click, or blink, or inhale or whatever minor action they must take to try it. And, once they’ve tried it, they need to find it useful (or at least highly entertaining). If your users aren’t clear on the value proposition, then they have to “discover” it for themselves. That means they need to think and/or work, and there go those barriers again, shooting upward.

A clear value proposition helps you communicate to the engineers, designers, to investors, advertisers, and most importantly your users. It makes every decision easier because it encapsulates your ultimate goal. Providing something valuable for somebody. Even if the value is that users can participate in creating the value.

We don’t always have the chance to recognize, let alone challenge our fundamental assumptions. I really enjoyed this chance to think about this one.