One of the most important things I learned working at a number of startup’s and running a few my own is that a startup is truly, distinctly different than a large company. In a startup, you’re working to determine your proposition and create a beachhead with your first key customers. In a line of business where you’re operating against a known proposition, you’re refining, scaling, competing, and innovating on an incremental basis. This proposition (and more) was crisply articulated in Steve Blank’s ‘Four Steps to the Epiphany’ then refined and augmented in Eric Ries’ ‘The Lean Startup’. These ideas are well accepted and embraced.
My area of interest with ‘Starting a Tech Business‘ is to understand why relatively few companies and startup’s are implementing these ideas fully, and the practical aspects of how to broaden the base of firms (and individuals) who can benefit from these new best practices. The balance of this post first describes the key differences in approach between established business vs. startup’s (applies equally to businesses within an existing company as it does new companies). It then describes five key tips on actually being lean that I’ve found especially useful.
The Aping Fallacy
Lean startup’s need small, hands-on teams that can work together seamlessly with a ruthless focus on discovering a product/market fit. The organizational skills and experience that made someone successful in an established company or even in a traditional startup with lots of funding behind it aren’t necessarily a good fit in this lean environment. In the lean environment, doing trumps delegation, observation trumps opinions, and hands-on trumps hierarchy.
In summary, lean startup ≠ established business:
The aping fallacy is that by acting like a big, established company a startup progresses towards their goal of having a large, scalable line of business. We’ll look at examples in the next section.
This is not to say that lean startup’s are good and traditional organizational structures are bad. Plenty of startup’s falter because they fail to build scalable organizations after they’ve identified a product/market fit. At Leonid (my company), we run both models simultaneously: we have a relatively traditional mission and process-driven structure for our existing lines of business and we create lean customer development teams where we’re starting up new products.
Let’s walk through an archetype for both the ‘old’/aping pattern for startup’s and the ‘new’/lean pattern. These examples show new companies but the pattern fits new lines of business in existing companies as well- just substitute steering committee for VC, etc.
The Old/’Aping’ Pattern
The diagram below shows a simplified view of the events from a startup’s founding to its first major board meeting:
Everyone wants the business to be big quick so they ape the things you can use to grow a business with an established product/market fit- lots of cash, staff that know how to scale, recipes for customer acquisition that work when you know what you’re selling. The problem, of course, is that the business isn’t on an established track yet, not having identified its key proposition and reproducible recipe. Having a bunch of money from VC’s (or your company’s board) is nice in that it gives you runway to succeed, but not if you’re being asked to achieve liftoff shackled to a freight train of unrealistic expectations.
The New/Lean Pattern
The diagram below shows the same chain of events with a lean approach:
Ah, much better. Here, in the worst case, at least you’re learning things you can put to use. So, why doesn’t every startup look like this? I’ve picked the five tips below based on my own work and experience mentoring entrepreneurs and ‘intrapreneurs’. They’re practical, readily actionable, and I think they’ll help you get where you want to go faster and more reliably.
Five Tips for Operating a ‘Lean’ Team
1. Make Yourself a Broad-Based Contributor
With only moderate exertion, you can learn a lot of the skill sets you need to move your lean startup through its first few paces. One thing I see tripping up non-technical founders (and managers) that I mentor is that they bring in developers too early in the process. Bringing in the developers before they really know what they want to build often ends up wasting cash and goodwill. By all means, bounce ideas off technical colleagues and, no, you don’t necessarily have to learn to code yourself to be successful. What I would do is create for yourself the progressive foundation of knowledge described below:
First, learn the best practice ‘foundation concepts’. If you want something quick, I screen casted an overview across two talks: ‘Much Ado About Something‘ and ‘It Works When You Do It‘. There’s also a recommended reading list in the Resources section of this site. Not to over-sell the goods, but ‘Starting a Tech Business‘ does provide an introduction to these concepts. As with most things these days, there are also a lot of good spot resources you can find by Google’ing around.
Second, while you don’t necessarily need to learn how to code, you should acquire a baseline technical literacy. Same deal on resources- there’s a list of books under Resources, ‘Starting a Tech Business’ offers an intro., and you can find some spot resources just Google’ing around. I also recorded a screen cast intro. to the model-view-controller pattern here. For more on what I mean by software fundamentals, see the description of chapter 3; for architecture fundamentals see chapter 4; for roles & systems see chapter 5. These chapter overviews may give you an idea about where to look for resources if you don’t have/don’t want to have ‘Starting a Tech Business’.
Third, I would work to understand agile as a ‘product owner’/product manager. This is a great platform for collaboration with your development team and understanding a few of its concepts and practices. I introduce it in chapter 5 and chapter 6, there are ample resources and the web, and Greg Cohen’s book ‘Agile Excellence for Product Managers‘ is great for a more extended introduction.
Finally, with this foundation under you I’d consider whether you want to code or dive into some other specialty. This may sound like a lot but it’s something that a determined participant can cover in a few weeks.
2. Carefully Articulate Assumptions
Eric Ries in ‘The Lean Startup’ introduced the idea of articulating a hypothesis for your business, organized as a set of assumptions, and proving it out as an organizing heuristic for the startup. Of the teams I work with, all of them are familiar with the idea. That said, all of them have benefited from spending some additional time detailing the assumptions and experiments to prove or disprove them. The idea of applying the scientific to a startup is intuitive and that’s part of its appeal. But actually doing it takes some real practice, concentration, and perseverance (I’ve learned the hard way, believe me). I highly recommend seeking out examples to compare against your work.
3. Carefully Prioritize Your Assumptions
Operating a startup means managing a difficult pairing of urgency and uncertainty. There are a lot of things that could be done. Making sure you’re doing the right ones requires ruthless prioritization. Once you have your assumptions, prioritize on the basis of which assumptions are most important and easiest to prove- these you obviously want at the top. Then work you way down. Don’t let other stuff distract you.
4. Always Be Observing
Above all, being in a startup is a learning opportunity. You’re charting new territory. Once you stop thinking of yourself as a frontiers(person) observing new territory that you don’t fully understand, you’ll stop learning. This is a possible hand brake on your progress that you need to carefully avoid.
5. Be Ready to Revise
This is a corollary of #4: when you observe something that disproves one of your key assumptions, be ready to revise. Remember, that’s agility is a key competitive advantage over the established substitutes and competitors you need to exceed.
And you?
In the same spirit, I’m constantly learning about effective practice myself. If you’d like to post back in any fashion, it would be great to hear from you. Below are a few starter questions-
If you work in an established company:
- How do you organize for new products/lines of business vs. existing ones?
- What specific techniques have you found most effective?
- What things do you wish you’d done differently?
- What resources helped you along your way?
If you’re doing a startup:
- How have you planned out the business? What do you use to keep on track?
- What specific techniques have you found most effective?
- What things do you wish you’d done differently?
- What resources helped you along your way?
If you like to….
Post: please see the form below
Tweet: I’m @cowanSF; you can also use the button at the top of this page to generate your own Tweet
Email: I’m acowan@alexandercowan.com
Use Linked In forums: If you reached this on a LinkedIn forum, naturally, that’s a good place to post as well.
