Entrepreneurship Begins With Demand

Many people who are new to entrepreneurship approach the world of business in some rather funky ways. Quite often they come up with solutions first — or at least what they think is a solution. Then they try to convince people to buy, hoping that those people will somehow see the value in their solutions.

That’s a recipe for glorious failure.

Sure it could work sometimes, especially if you have millions of marketing dollars to help create demand, but for small businesses it’s not a very wise approach. For a sustainable business you’ll want to see some evidence of genuine demand for what you’re going to sell — ideally before you go through all the work of starting a business or creating a new product or service.

Many amazing businesses have been launched because someone noticed an existing problem or some kind of demand for a solution or improvement, and they found a way to fulfill that demand reasonably well.

When I started my computer games business in 1994, I didn’t know if there was any demand for what I was creating. I created some games, but hardly anyone bought them.

Then I went to a game development conference where one of the co-founders of a very successful company explained in plain English the difference between creating games that sell well vs. creating games that don’t.

He said it came down to creating games that people clearly wanted to buy vs. creating games that the development team wanted to create. These goals aren’t necessarily in conflict. He explained how his company went from struggling for 8 years in a row to finally creating some mega-hits. They started paying attention to what kinds of games people really wanted to buy. Then they created games in those genres. Their games sold millions of copies.

It’s not rocket science, but it sure makes a difference.

I applied this advice on a fairly small scale, and my games business did much better. I targeted genres where I saw more demand than supply, and so I didn’t have to push so hard on the marketing front. I mainly just had to get the word out that my games would satisfy a particular type of player. And within a matter of months, those players were flocking to my website.

Erin’s intuitive reading business did well because people were already asking her for advice. People had been asking her for readings since she was a teenager. She mainly had to say yes to what was already showing up. When she began offering readings professionally, people began signing up right away. She got so much business that she had to go through several rounds of price increases until she reached a reasonable equilibrium.

If you want a sustainable business, it’s important to pay attention to demand. What do people want and need? What problems are they having? What sort of help are they looking for?

Quite often you’ll find things you love doing, but nobody else cares to pay for it. That’s fine. Enjoy those activities as your side hobbies. The demand may change in a decade or two.

Other times you’ll notice demand for something, but you’ll have no personal interest in helping out. That’s fine too. Let someone else fulfill those needs.

If you’re open to creating a sustainable business, be on the lookout for evidence of demand that you’d enjoy servicing.

When I started my personal development business, it was largely in response to existing demand. Before I ever wrote my first blog post, people were already emailing me every week with productivity questions, small business questions, motivation questions, etc. It wasn’t a stretch for me to say yes to that because I enjoyed writing about personal growth. But I didn’t start the website and hope the demand would be there. I saw clear evidence that the demand was already there before I started. I said yes to what was already showing up.

Marketing such a business is a lot easier than marketing a business where the demand is unclear. If the demand is already there, then marketing is mainly a matter of letting people know that a solution or service exists and that it may satisfy them.

But if there’s little or no demand, then marketing amounts to trying to convince people they need something, and they may very well disagree. That kind of marketing is a struggle, especially for a small business without a huge marketing budget.

Demand doesn’t have to be personal for it to matter. People don’t have to be asking you to solve their problems. They just have to be asking for a solution.

If you’ve started a small business, and it seems like an uphill battle to generate sales, could it be that you’re providing something hardly anyone wants? If that’s the case, try not to see it as a personal failure. It happens often. It’s all part of the entrepreneurial calibration process. You’ll eventually figure out that sales matter, and it’s easier to generate sales by cooperatively giving people what they want as opposed to trying to convince them to want what you’ve decided to give.

View the original article here

What’s Your Start-up’s “Bus Count”? 7 Myths of Entrepreneurship and Programming

(Photo: Stuck in Customs)

For the last two years, one name has come up again and again when talking with A-class start-up investors: Pivotal Labs.

See, Pivotal Labs quietly helps dozens of the fastest-growing tech companies in the world, including freight trains like Groupon and Twitter. If your start-up needs to get good coding done quickly, as in lightning fast — or if new hires need to get good at coding quickly — top venture capitalists are likely to look over their shoulder and confide: “Call Pivotal Labs.”

I first met the Founder of Pivotal Labs, Rob Mee, when one of the start-ups I advise, TaskRabbit, began working with them.

One thing is immediately clear: Rob is obsessed with how to get obscenely high output. But that’s nothing new. Here’s the differentiator: he’s obsessed with how to get obscenely high output with sustainable effort. One of his first remarks to me was “3am with Jolt and pizza can be fun, but it’s a myth that it’s the fuel behind scalable success…”

My kinda guy.

I then posed a few questions:

How do you create a scalable, bullet-proof business? In this case, “bullet-proof” meaning that there’s no single point of failure — it won’t nose dive if any single player (like you) is taken out… or opts out.

What are the myths of tech product creation (software specifically, and entrepreneurship more broadly) that he’d like to expose?

This post contains his answers.

Think software doesn’t apply to you? If you’re in business, rest assured that at least a few principles of good software development most definitely apply to you. Translate them into your world and prosper.

Software development is a rapidly evolving field that got off to a very rocky start.

Conventional wisdom for many years was that software engineering should be like other types of engineering: design carefully, specify precisely, and then just build it – exactly to spec. Just like building a bridge, right? The problem with this approach is that software is just that. Soft. It’s endlessly malleable. You can change software pretty much any time you want, and people do. Also, since software can be used to model just about anything, the possibilities for what you can ask software developers to do are pretty much infinite. Want to simulate a circuit in software? Go ahead. Run a bank? No problem. Connect half a billion people to their friends? Why not, piece of cake. Not only that, but what we ask programmers to produce changes in the middle of the development, often in unpredictable ways.

This is not bridge-building.

Denying the reality of constant change doomed many software projects, for many decades, to either abject failure or huge budget overruns. So why did an entire industry hew to this conventional wisdom that flew in the face of all evidence? Hard to say. Finally, however, there has begun to emerge a new consensus: software development needs to respond well to change. In fact, it needs to be optimized for change. Nowhere is this embraced more than in today’s web start-up development community. So-called agile methods have gained currency, and the “lean start-up” movement calls for exceedingly rapid change, often automated and based on experimentation with the live system.

So we’re all good, right? Not so fast. In spite of the acceptance of more agile methods, there’s plenty of received wisdom hanging around… and most of it ought to be thrown out the window.

1. Myth: You have to hire “ninjas”.

The myth of the hero hacker is one of the most pervasive pathologies to be found in Silicon Valley start-ups: the idea that a lone programmer, fueled by pizza and caffeine, swaddled in headphones, works all hours of the night to build a complex system, all by himself. Time out. Software development, it turns out, is a team sport. All start-ups grow, if they experience any meaningful success. What works for a lone programmer will not work in a company of 10. And what’s worse, encouraging the hero mentality leads to corrosive dysfunction in software teams. Invariably the developers who do a yeoman’s 9-to-5, week after week, cranking out solid features that the business is built on, lose out to the grasping egomaniacs who stay up all night (usually just one night) looking to garner lavish praise. Rather than reward the hero, it’s better to cultivate a true esprit de corps.

2. Myth: Programmers need to work in quiet, without interruption.

This makes sense … if people are working on their own. Every interruption does indeed break concentration, and it takes a while to get back “in the zone”. Some well-known software companies even insist that each programmer have their own private office. That way they’ll never be interrupted, right? Except that modern-day interruptions have little to do with an actual person tapping you on the shoulder, and everything to do with instant messaging, mobile phones, Facebook and Twitter, email, and the music coming in through headphones that programmers swear helps them concentrate. The reality is that most programmers working on their own only spend a small fraction of their day actually programming: the interruptions are legion, and dropping in and out of a state of concentrated focus takes most of their day. There is a solution, however: pair program. Two programmers, one computer. No email, no Twitter, no phone calls (at least not unscheduled; you can take breaks at regular intervals to handle these things). If you do this, what you get is a full day of pure programming. And “getting in the zone” with someone else actually takes almost no time at all. It’s a completely different way of working, and I maintain that it is far more efficient than working alone ever can be. And in fact, with the current level of device-driven distraction in the workplace, I’d suggest it is the only way that software teams can operate at peak efficiency.

3. Myth: Start-ups run hot, so we’re just gonna have to burn everyone out.

Working crazy hours doesn’t get you there faster. In fact, it slows you down. Sure, you can do it for a week. But most start-ups plan to be around for a little longer than that, and developers will going to have to keep programming for months, if not years, to build a successful product. Many start-ups operate as if the pot of gold is just around the corner; if we only work a little harder, we’ll get there. Pretty soon developers burn out, and simply go through the motions of working long hours without any corresponding productivity. Working intensely, for shorter periods of time, is far more effective. Pivotal has helped hundreds of start-ups build systems, and has done it on a strict 40-hour week.

4. Myth: Looming deadlines necessitate shortcuts.

Many software teams use the excuse of a high-pressure market and the need to ship product right now as an excuse to do shoddy work. Writing tests goes by the wayside; careful design is forgotten in the rush of frenzied hacking. But software teams are no different than other teams we’re all familiar with, and the way high-performing teams succeed is not to lose their cool: on the contrary, when the pressure’s on, you stay frosty, and let your training carry you through. How many times have we heard stories of remarkable performance under unimaginable pressure – whether it be military, professional sports, or a pilot landing a plane on a river – and the explanation almost invariably involves the heroes saying, “We trained for this situation.”

5. Myth: Developers should take ownership of their code.

Ownership sounds good. As American as apple pie. Personal responsibility, right? But “ownership” in a software team implies that only one developer writes – and understands – each module of code. This leads to defensiveness on the part of the developer. It also creates risk for the business owner, since the loss of one person could slow the team, or potentially cripple the business if they were responsible for a particularly crucial part of the system. A much healthier process allows any developer to work on any code in the system. Pair programming facilitates this, because knowledge is passed from person to person. The so-called “bus count” (how many people in your team have to get hit by a bus before you’re all dead in the water) is a critical indicator of risk for the software start-up. And it’s not really a bus we’re talking about here – it’s your competitors, who would love to hire your best developers. The more people who understand the whole system, the stronger and more resilient your organization.

6. Myth: You need a quirky hiring process.

Would you hire an actor without an audition? You wouldn’t last long as a director if you did. But this is exactly what almost all companies who hire software developers do today. Usually the process involves talking through an applicant’s experience with them. And that’s all. Imagine asking an aspiring actor if they enjoyed their role as Hamlet. Did you play him well? Good. You’re hired! Many famous software companies propose brainteasers for their applicants. Some top companies even give candidates an IQ test. The best of them run candidates through a simulated software problem on a whiteboard. This is a sorry state of affairs. I’m going to state (what should be) the obvious: the only way to hire good programmers reliably is to program with them. I run programmers though a one-hour, rapid-fire, pair programming interview – and that’s just the start. Having done it over a thousand times, I can score developers relative to each other on a 100-point scale. What do I look for? Mental quickness, ability to think abstractly, algorithmic facility, problem-solving ability. And most importantly, empathy. Because collaboration is the most important thing we do, and it doesn’t matter how smart you are if you can’t relate to how other people think.

7. Myth: Specialization is essential.

Managers, quite naturally, want to attack problems by dividing and conquering. In software teams, this often manifests as an urge to force specialization. Front-end vs. back-end, database administrators, and so on. Brad Feld suggests in his blog that every team should have one “full-stack programmer”, someone who’s a true generalist. He’s right, but he’s not going far enough. Everyone, in every team, should know the full stack [Tim: read Carlos Bueno's piece here]. Why? Because specialization makes a team fragile. Remember that bus count? Every specialist is a liability; if they leave, and you can’t replace them, you’re sunk. Not only that, but it makes a team sluggish. Specialists need to make their disparate parts of the system communicate through defined interfaces. In effect, they end up writing informal contracts with each other about how to do it. This leads to a lot of overhead, and often defensiveness or finger-pointing. At Pivotal, every developer works on every level of the system, from HTML and JavaScript, to Ruby, and down to the database. And the argument that specialists will be better at a particular layer of the system if they’re allowed to focus on it doesn’t really hold water. The state of software technology today is simply not that difficult. Programmers are better off knowing all layers and how they interoperate. By the way, another important implication of all this: you don’t need to hire for a particular technology. Ruby programmers in short supply? Fine, hire a Java programmer and train them in Ruby (pair programming works great for this). Someone defines themselves as a “server-side” programmer? No problem, make them do JavaScript, they’ll pick it up.

If they’re any good, that is.

###

Read more about Pivotal Labs and find their collection of tech talks here. If you’re in SF or Boston, try TaskRabbit while you’re at it :)

Click here to browse this blog’s other Entrepreneurship posts (covering everything from Twitter and FUBU to selling companies and angel investing).

Posted on June 7th, 2011

View the original article here