Archive for April, 2012

Susan Cain: The Power of Introverts on

Written by Theresa Shafer. Posted in Rules of Thumb

An interesting TED talk by Susan Cain on the power of introverts: how introverts impact innovation and creativity.

Here are some key points she makes (see full transcript)

  • When it comes to creativity and to leadership, we need introverts doing what they do best.
  • A third to a half of the population are introverts.
  • You need to understand what introversion is. It’s different from being shy. 
  • Shyness fear of social judgment.
  • Introversion is how you respond to stimulation, including social stimulation.
  • Extroverts crave large amounts of stimulation, introverts feel most alive and capable when they’re in quieter, more low-key environments.
  • The key then to maximizing our talents is for us all to put ourselves in the zone of stimulation that is right for us.
  • Solitude is a crucial ingredient to creativity.
  • Much better for everybody to go off by themselves, generate their own ideas freed from the distortions of group dynamics, and then come together as a team to talk them through in a well-managed environment and take it from there.
  • Stop the madness for constant group work. Let people come together and serendipitously have an exchange of ideas. It’s great for introverts and it’s great for extroverts. But we need much more privacy and much more freedom and much more autonomy at work.
  • Go to the wilderness and have your own revelations. We could all stand to unplug and get inside our own heads a little more often.

Four Excerpts from Valve’s Employee Handbook That Belong In Yours

Written by Sean Murphy. Posted in 5 Scaling Up Stage, Rules of Thumb

A link to Valve’s Employee Handbook made it to front page of Hacker News recently and I can see why, it makes for very interesting reading. Here are four excerpts you should consider for your company’s employee handbook:

“This company is yours to steer–toward opportunities and away from risks.”
Valve Company Handbook (first edition 2012)

This recognizes a reality that echoes Kevin Kelly’s “we are all steering.” I sometimes encounter entrepreneurs who want to hire (or have hired) employees who are waiting to be told what to do;  it’s amazing how little leverage this model affords a business. It may be necessary for a junior new hire but Valve’s model undoubtedly unleashes a lot more creative energy and insight.

“We are all stewards of our long-term relationship with our customers. ”
Valve Company Handbook (first edition 2012)

In his 2011 analysis of where Cisco had failed to manage incentives, Larry Lang observed that a mature firm faces serious challenges in maintaining an employee focus on customer relationships when cultivating internal relationships is often a more reliable model for advancement and increased compensation. What is significant about Valve’s approach is that they trust everyone to interact with customers and feel responsibility for the relationship–it’s not just the job of the sales or marketing or customer service group.

“Everyone is a designer. Everyone can question each other’s work. ”
Valve Company Handbook (first edition 2012)

Intel has a model for “constructive confrontation” as well; the risk is that it can encourage rude and destructive behavior. In his description of “The Cabal: Valve’s Design Process” (linked from the Handbook) Ken Birdwell outlines some lessons learned from the intense interactive group sessions:

  • Square Pegs: practically speaking, not everyone is suited for the kind of group design activity we performed in the Cabal, at least not initially. People with strong personalities, people with poor verbal skills, or people who just don’t like creating in a group setting shouldn’t be forced into it. We weighted our groups heavily toward people with a lot of group design experience, well ahead of game design experience. Even so, in the end almost everyone was in a Cabal of one sort or another, and as we got more comfortable with this process and started getting really good results it was easier to integrate the more reluctant members.
  • Smaller teams initially. For current projects, such as Team Fortress 2, the Cabal groups are made up of 12 or more people, and rarely fewer than eight. The meetings ended up being shorter, and they also ended up spreading ideas around a lot quicker, but I’m not sure I’d recommend that size of group initially.
  • Include an expert from every functional area (programming, art, and so on). Arguing over an issue that no one at the meeting actually understands is a sure way to waste everyone’s time.
  • Write down everything. Brainstorming is fine during the meetings, but unless it’s all written down, your best ideas will be forgotten within days. The goal is to end up with a document that captures as much as is reasonable about your game, and more importantly answers questions about what people need to work on.
  • Not all ideas are good. These include yours. If you have a “great idea” that everyone thinks is stupid, don’t push it. The others will also have stupid ideas. If you’re pushy about yours, they’ll be pushy about theirs and you’re just going to get into an impasse. If the idea is really good, maybe it’s just in the wrong place. Bring it up later.

Because Valve has no formal hierarchy, or has a fluid hierarchy, they need a process like cabals to act as a crucible for making sure that all of the relevant people have been consulted and a decision is quickly communicated widely. I think there are different process needs when you are in discovery or exploration mode vs. delivery or execution mode and the nature of questions or challenges need to align with needs of the project.

It helps to make predictions and anticipate nasty outcomes.
Ask yourself “what would I expect to see if I’m right?”
Ask yourself “what would I expect to see if I’m wrong?”
Then ask yourself “what do I see?”
If something totally unexpected happens, try to figure out why.

There are still some bad ways to fail. Repeating the same mistake over and over is one. Not listening to customers or peers before or after a failure is another. Never ignore the evidence; particularly when it says you’re wrong.

Valve Company Handbook (first edition 2012)

I think this model for planning is the single more important take-away. You need to write down in advance what success, failure, and the boundaries of the expected are. In the middle as you are making the switch from discovery to delivery it’s easy to persevere needlessly or pivot endlessly or simply stall. Being clear about what constitutes a success that merits further investment, a failure that triggers plan B, and an anomaly that requires further study make it less likely you will lose your way.

Michael Abrash posted “Valve: How I Got Here, What It’s Like, and What I’m Doing” on April 13, shedding more light on Valve’s model:

So Valve was designed as a company that would attract the sort of people capable of taking the initial creative step, leave them free to do creative work, and make them want to stay.
Trust is pervasive. All of Valve’s source code is available to anyone in Perforce, and anyone at Valve can sync up and modify anything. Anyone can just up and work on whatever they think is worth doing.
To be clear, Valve hasn’t magically repealed the realities of developing and shipping products. We’re all human, so teams sometimes argue (and sometimes passionately) about what to do and how to do it, but people are respectful of each other, and eventually get to a consensus that works. There are stresses and more rigid processes when products are close to shipping, especially when there are hard deadlines for console certification. Sometimes people or teams wander down paths that are clearly not working, and then it’s up to their peers to point that out and get them back on track.
Also, don’t think that people randomly come in every day and do whatever they feel like doing.
People commit to projects, and projects are self-organizing; there are leads, but they’re chosen by informal consensus, there’s no prestige or money attached to the label, and it’s only temporary – a lead is likely to be an individual contributor on their next project. Leads have no authority other than that everyone agrees it will help the project to have them doing coordination. Each project decides for itself about testing, check-in rules, how often to meet (not very), and what the goal is and when and how to get there. And each project is different.
It’s hard to believe it works, but it does. I think of it as being a lot like evolution – messy, with lots of inefficiencies that normal companies don’t have – but producing remarkable results, things that would never have seen the light of day under normal hierarchical management.
Valve’s long string of successes, many of them genuinely groundbreaking, is strong evidence that the hypothesis that creative people are the key to success is in fact correct, and that the structuring of Valve around those people has been successful.

Standing Out From The Crowd

Written by Theresa Shafer. Posted in Customer Development

So much marketing is “me too”, if you have read one press release or marketing material you have read them all. It is always a trick about how to reach your audience and stand out from the crowd by being different. In an age of low-cost email campaigns and social media, we are actually finding that direct mail is standing out and cutting through and reaching prospects. Mailing traditional newsletters, hand-written letters or simply sending out postcards are working. People like getting mail!

3 Reasons I Like Postcards

  1. Cost effective –  $20 for 500 postcards
  2. Don’t have to open an envelope
  3. People will actually post them on their office wall!

Below are couple of our favorite postcards:

Don’t forget to add a QR code.

The Technology is Nothing Without the Team

Written by Sean Murphy. Posted in 2 Open for Business Stage, 3 Early Customer Stage

I remember once talking to my high-school physics teacher, who had been one of the leading teachers in our district for decades.

“Don’t you get tired teaching physics?” I asked him one day.

“I don’t teach physics,” he replied. “I teach students.”

The same wisdom applies to securing financing for startups:  investors don’t fund technologies, they fund people. The corollary is that companies don’t bring technologies to market, they bring products to market.

Neil Kane in “Culture Clash: Scientists Vs. Entrepreneurs

When we talk to prospects for our market creation and market exploration services we always want to know if they have “working technology.” This has a different meaning than a mainstream customer might infer. It means that the team can deliver results that would otherwise be unavailable to their prospects at a given price within a given timeframe.

Most bootstrapping firms start out by delivering a service, or at least wrapping their product in a thick protective blanket of consulting to protect their customers from any sharp unfinished edges. And if you have ever used a product too early you know that the jagged edges of tomorrow can scratch some pretty deep wounds that are slow to heal and may leave impressive scars on what was once a promising career.

This is why early customers look hard at the people in your startup: they know that the technology cannot be divorced from the team and that how you respond when your product is producing unsatisfactory results is the most important question they have to answer. Because,  as Gerald Weinberg advises, “nothing new ever works ” and sooner or later you will have to respond.

This means that it’s critically important that you act from the beginning to build trust and demonstrate that you are reliable, by actually being trustworthy and reliable.  That does not mean you have to be perfect or offer a perfect product. Just that you and your team make it better over time and promptly address any issues or defects.

See also “My Interview with Peggy Aycinena

Worry About Scaling After You Find Your Niche

Written by Sean Murphy. Posted in 4 Finding your Niche

“We tell our disruptive teams to not do volume forecasts. Do not do a spreadsheet with volume forecasts on it, because it is unforecastable.  You cannot really know. So why waste time doing bogus numbers that are unknowable.  The finance department may ask for them, so spend five minutes, do something quickly, but the leadership should not focus on those numbers. They are wrong, you just don’t know in what direction. Instead we have teams focus on how deep is the customer problem that’s unserved and how good is our solution at solving it. If  those two are strong, then we have a reasonable shot at a good business. If either of those is weak, then no matter what the spreadsheet says, no matter what the volume forecast says, there is not a business there.”

Scott Cook in a 2007 interview with Innosight (starts at the 2:30 mark but all six minutes are worth watching)

Peter Cohan‘s “Situation Slide” asks six questions to help a sales team prepare for a demo:

  1. Job Title & Industry: Name and role of each decision maker attending demo
  2. CBI (Critical Business Issue): What is the major problem he/she has?
  3. Reasons: Why is it a problem or what is the problem due to?
  4. Specific Capabilities: What capabilities are needed to address the problem?
  5. Delta: What is the value associated with making the change?
  6. Critical Date or Event: When does the change need to take place (and why)?

I have bolded CBI and Delta because these correspond to Scott Cook’s “how deep is the customer problem that’s unserved” and “how good is our solution at solving it.” These are the key questions for determining whether or not you have a niche.  Actually they are key questions to answer to secure an early customer, but when the same problems and same delta or impact recurs across customers who will reference each other’s buy decisions you have found your niche.

It’s at that point you can worry about scale. But especially for bootstrappers, a solution that doesn’t scale can still generate not only cash flow but valuable learning about real problems so that you can meet a deep customer need in a distinctively useful way. As Cook points out in the video, you can worry too much about building a $100 million or a billion dollar business when making sure you are having an impact on a problem a customer cares about can secure you  a $1M to 10M business that can lay the groundwork for a larger business. This why we put the “finding your niche stage” after “early customers” but before “scaling up” in our startup stages model.

If you want to learn how to give a “Great Demo” Peter Cohan’s next open enrollment workshop is May 23 in San Jose.

A Beta Customer Is Not A Tester Or A User But An Early Customer

Written by Sean Murphy. Posted in 3 Early Customer Stage

This post is an explanation of  why we call the third of our five stages of startup growth the “early customer stage” and not “beta.”

The term “beta customer” conflates three categories of people who are using your product in a way that’s not healthy for your long term business prospects if you are selling to business users, in particular early adopter or pragmatic enterprise users.

Quid Pro Quo

  • Beta Tester:  someone you pay to evaluate your software and provide written feedback and perhaps an oral debrief.
  • Beta User: a friend, acquaintance, or friend of a friend doing you a favor using your product.  You can ask for an oral debrief or a written feedback but remember that they are doing you a favor.
  • Early Customer:  someone who believes that your product will help to solve a problem or meet a need and who you believe has a  reasonable prospect of deriving value from your product. If they are evaluating your software they may not have paid for it yet but the expectation is that they will pay if they achieve a satisfactory outcome in a given period of time that is mutually agreed to.

Testing Your Product:

  • Beta Testers are anxious to test your product to the extent that you are paying them.
  • Beta Users are willing to test your product to return a favor or barter for a future favor.
  • Early Customers are anxious to see if your product will produce a better result than the existing alternatives that are available to them. They are not anxious to “test” your product. If you are wise you will ask them for data or otherwise attempt to verify that your software will meet their basic needs before you make it available to them.

Reporting Bugs:

  • Beta Testers like to report bugs because it’s proof of their value and that they deserve to be paid.
  • Beta Users like to report bugs because they are concerned about their impact on your business reputation and potential customers’ experience.
  • Early Customers normally don’t like to report bugs and tend to restrict themselves to ones that they want fixed.   As far as they are concerned the best outcome is that they can get the results they need with the software as is. If they are “documenting bugs’ they are having a service interaction that is unsatisfactory. More fundamentally, they are not pointing out “technology problems’ as much as business, relationship, and reputation problems.

None of this is to imply that you cannot launch experimental offerings for current customers or new categories of prospects, but it’s a part of managing your business in the same way that altering any other aspect of your engagement or service delivery process would need to be managed.

If you are selling to business you cannot adopt the same attitude that a Google or Twitter has in providing a free service to an audience that they plan to monetize:  you want your product to be a better alternative than anything else they can afford at any point in time that they are using it. This does not mean that it has to be perfect, just better for the metrics and results that your customers  value.

“Your brand is the promises that you keep.”
Kirstin Zhivago

Quick Links

Bootstrappers Breakfast Link Startup Stages Clients In the News Upcoming Events Office Hours Button Newsletter SignUp