- You don't know anything.
- If it's your first time, this applies to everything from incorporation to insurance to interns. Unless your entire team has worked together before in pretty much the same way, you don't know how the team dynamics will shake out and how that will affect your offerings. And unless you're doing the exact same thing that you've done before (er, why would you?), there are a lot of unknowns on product, market, roadmap etc. But, this doesn't, and shouldn't, stop you. You build your business plan, trying to apply some probability to the unknowns; you bring new people on board mitigating the risk with in-depth communications (or, personality tests per the new trend ); you make innumerable changes to your product design based on continuous analysis and prototypes - in short, you adjust and adapt constantly while moving forward rapidly. And you will someday reach a space where your plans are solid for a week, a month, and then wow, a whole quarter and you can confidently put your mission up on the wall without having to bring it down for tweaking.
- You don't have anything.
- This may not apply to those who're able to land funding (or put in money themselves) right from the get go, but most startups don't have money in the beginning. Which means you don't have enough people, so your architect does competitive analysis, while the CEO's plugging away at QuickBooks and your CTO's ordering coffee as there's no admin. If you do have some money, you don't have full product requirements developed, or your target customer profiled in detail, or the architecture all figured out. In the early stages, your dreams are outpacing your means by many miles.
- You are obsessed.
- The team believes they're all rock stars and what they're working on is going to change the world, and you all get a little weird because you can think of nothing else in a sustained fashion. So when a friend talks about traveling to Peru your mind's wandering off wondering if that could be a future market, and when you're invited for a weekend getaway you don't jump for joy because you'd have to reschedule your Saturday con call. The early stage is fueled by passion, which is a good thing, given #1 an #2 above (it does get more tempered with time).
Channeling the inner entrepreneur who views life as a startup. Musings about people, their spirit, the startup ethos and the entrepreneurial attitude, with an emphasis on education and social ventures. The 'how-to'? Not so much. But definitely the why, the what and the whatever.
The Early Stage Startup Environment
Last week I had the unusual experience of trying to describe what an early stage startup environment is like - to three different people. Why unusual? Maybe because most of the people I run into in Silicon Valley have experience with, or knowledge of, startups - everyone seems to have a friend or acquaintance who's given them the low-down on the startup world. So, I had to actually stop and think before I replied the first time, and the second time I realized I'd missed something and the third time I realized I was rambling - so I decided to take a stab at writing down my thoughts.
Startup CEO's Role - Part 1
There are a lot of things that the Founder CEO should be doing, and a lot of things s/he gets involved in, from pricing discussions to the brand of coffee to be bought. At the entrepreneurship conference I'd mentioned in a previous post, one speaker was very emphatic on what startup CEO should be doing: getting the team committed to the vision, holding people accountable, and communicating constantly. The more I think about it, the more it seems that they all boil down to just one thing: communicating.
Every once in a while I feel that the whole communication thing is being overdone and let's get on with the execution already. And then something happens which brings home the point that the communication didn't happen as it should and created a glitch in, what else, execution. A case in point: we'd started work on a 'proof of concept' and our small team got together and defined what we wanted to the engineer. At that time, there was some talk about what platform the POC should be built on and I'd responded I didn't care what the platform choice was as it would be a throw-away - we'll figure it out before we started the product development, while the POC would be used for presentation, validation, discussion etc., for a few months. The engineer who was developing the POC got all that, but unfortunately construed the 'throw-away' part to imply that once it was done it would be static, i.e., the POC itself may not enhanced or modified. That's about as likely in a startup as having a business plan cast in stone. Luckily, he was able to mitigate the effects of the choices he'd made based on this misunderstanding, but it was not without some cost.
In this case it was not a lack of communication that caused the disconnect, but forgetting that slangy phrases that are open to interpretation should not be used in specifications (even if it's only in a casual conversation), and that not everyone has the same grasp of the big picture as you do and may interepret statements differently (most engineers should not be expected to think like the CEO, regardless of how many 'vision' and 'strategy' sessions you may have). It's much better to spell it out than throw it out.
And this is just the tip of the iceberg. When I think of all the other nuances of communications in a startup: dealing with different styles, personalities, levels of expertise, virtual teams, and that's not even considering the external constituents such as investors, I think it's time to redefine the role. It should be Chief Communications Officer, because there's no execution without effective communication. (And no, lots of meetings do not make for good communications, and meetings are a whole different topic.) Startup CCO: it's a good way to remember what you're supposed to be doing.
Every once in a while I feel that the whole communication thing is being overdone and let's get on with the execution already. And then something happens which brings home the point that the communication didn't happen as it should and created a glitch in, what else, execution. A case in point: we'd started work on a 'proof of concept' and our small team got together and defined what we wanted to the engineer. At that time, there was some talk about what platform the POC should be built on and I'd responded I didn't care what the platform choice was as it would be a throw-away - we'll figure it out before we started the product development, while the POC would be used for presentation, validation, discussion etc., for a few months. The engineer who was developing the POC got all that, but unfortunately construed the 'throw-away' part to imply that once it was done it would be static, i.e., the POC itself may not enhanced or modified. That's about as likely in a startup as having a business plan cast in stone. Luckily, he was able to mitigate the effects of the choices he'd made based on this misunderstanding, but it was not without some cost.
In this case it was not a lack of communication that caused the disconnect, but forgetting that slangy phrases that are open to interpretation should not be used in specifications (even if it's only in a casual conversation), and that not everyone has the same grasp of the big picture as you do and may interepret statements differently (most engineers should not be expected to think like the CEO, regardless of how many 'vision' and 'strategy' sessions you may have). It's much better to spell it out than throw it out.
And this is just the tip of the iceberg. When I think of all the other nuances of communications in a startup: dealing with different styles, personalities, levels of expertise, virtual teams, and that's not even considering the external constituents such as investors, I think it's time to redefine the role. It should be Chief Communications Officer, because there's no execution without effective communication. (And no, lots of meetings do not make for good communications, and meetings are a whole different topic.) Startup CCO: it's a good way to remember what you're supposed to be doing.
The first test
This week was a very exciting one. We just had the first group of users test our product (a small working model of our product actually) and it was a huge rush. I think it is the sweetest thrill for an entrepreneur, even more so than getting funding, because the raison d'etre for your startup is building something that your customers will want and use.
There's a world of difference between theorizing about how the customer will use the product and actually watching someone use it. We did the usual, starting with initial observations, known best practices (aka what others have done), some leaps of imagination and plain old common sense and built a prototype/model/demo (not quite ready to be the alpha version). We had lined up a bunch of users to give it a go and give us feedback, and we thought the date was far enough out to make sure everything was the way it should be.
But there we were, three days before the test, and our small team didn't feel confident that we should put the demo in front of users. It was functional, but it didn't have the look and feel of our product vision, and there was concern that it would turn off the users. But I didn't want to postpone, not only because of logistical issues, but because I knew that if we wait until our demo is 100% ready we've waited too long. And I had faith that the users will view it with goodwill and be able to differentiate problems from potential.
So, we got everything lined up as well as we could and charged ahead - and turned out to be a most satisfying experience. There were no disasters, and the expected problems were only viewed as features they'd suggested we improve. It was gratifying to see the proto being used the way we intended - and in ways we could have never imagined. And the many new ideas they generated are invaluable, the stuff that will make the product truly fit their needs. And best of all, at the end of it, we'd got rock solid validation that we're on the right track with the product. No surprise, I'm pumped!
There's a world of difference between theorizing about how the customer will use the product and actually watching someone use it. We did the usual, starting with initial observations, known best practices (aka what others have done), some leaps of imagination and plain old common sense and built a prototype/model/demo (not quite ready to be the alpha version). We had lined up a bunch of users to give it a go and give us feedback, and we thought the date was far enough out to make sure everything was the way it should be.
But there we were, three days before the test, and our small team didn't feel confident that we should put the demo in front of users. It was functional, but it didn't have the look and feel of our product vision, and there was concern that it would turn off the users. But I didn't want to postpone, not only because of logistical issues, but because I knew that if we wait until our demo is 100% ready we've waited too long. And I had faith that the users will view it with goodwill and be able to differentiate problems from potential.
So, we got everything lined up as well as we could and charged ahead - and turned out to be a most satisfying experience. There were no disasters, and the expected problems were only viewed as features they'd suggested we improve. It was gratifying to see the proto being used the way we intended - and in ways we could have never imagined. And the many new ideas they generated are invaluable, the stuff that will make the product truly fit their needs. And best of all, at the end of it, we'd got rock solid validation that we're on the right track with the product. No surprise, I'm pumped!
Subscribe to:
Posts (Atom)