Today was the final day of Startup Weekend and we dove right in, furiously researching our competition and doing market sizing analysis. The site was coming together very nicely and much of the day was spent working out bugs. Because the site was so far along, we had time to get some feedback from a designer on another team, which helped improve the look.
Since we had to prepare for pitches we ended up spending a lot of time putting the pitch deck together. This was a major challenge. Everyone had a different idea of what it should look like and the truth was that there were too many cooks in the kitchen. As the deck went back and forth and became more and more discontinuous, I became more and more frustrated with the direction things were going. Finally, I took a step back and said just one of us needs to own the deck and the others should be constrained to only giving feedback. The owner would be in charge of deciding whether and how to integrate feedback and would have the option of leaving it out. I didn't care whether this person would be me or someone else. I just wanted us to have the right information and to present a consistent story that flowed well. Cy took the lead on this and the rest of us continued working on gathering supporting data to include as well as giving feedback as the various slides came together.
I had a pleasant surprise about halfway through the day when I was talking with someone from another team. The team had started out building "a network for the 1%" and had pivoted into the exact idea I had pitched on the first night. I was glad to see someone working on this problem.
As pitches and judging kicked off, things got started with a great pitch from a 6-year-old for washable stickers. It's amazing how confident he was. When I was that age, I was incredibly shy. I still am, to be honest, but have gradually developed my confidence over time. I was super impressed and excited to see this future superstar entrepreneur.
Our pitch went great. The anti-climatic conclusion is that we didn't place in the top three. However, we did get great feedback from the judges afterwards. They liked the idea, but felt that there were technical challenges that were critical to the success of the business that we didn't solve. They admitted that it probably wouldn't have been possible to have solved them in the course of a weekend, but that's just how judging these kinds of things goes. Something else they felt came up short was that others had attempted to do what we were doing in the past and had failed. They felt we hadn't made a big enough leap to have a shot at escaping the same fate.
All in all, another great weekend of learning! While I'm sure I'll attend more Startup Weekends in the future, I'm really itching to do something over a longer duration where I can get more depth of experience and see the project through to growth or termination.
Sunday, May 20, 2012
Startup Weekend Seattle Day 2
Today I got a shotgun lesson in surveying potential customers. Last startup weekend, my team and I blasted friends and family with requests for survey responses. This resulted in around 40 responses. My goal this time around was to increase the number of responses by a significant amount, do a better job validating the assumptions in our business model, and avoid spamming friends.
To start out, we took a close look at the various elements of our business model and identified the key assumptions that enabled the business. Based on these, we clarified what we wanted to learn from our study, came up with a set of questions, and created a Google Form to capture the information. As we went back over our initial set of questions, we felt they were too complicated and that the amount of mental energy spent answering them would cause participants to disengage before completing the survey.
After modifying the surveys, we got feedback from the Startup Weekend mentors. We spent some one-on-one time with them walking through the survey and looking for feedback on the questions that were being asked. Interestingly, it was difficult to get this kind of feedback because we found that once someone started reading through the survey, they'd jump into responding to it and it took significant focus to keep the conversation on track and ferret out opinions of the positives and negatives about the questions and structure of the survey itself.
Here's a big lesson we learned. Every mentor we spoke with gave different opinions, frequently with advice that was contradictory to what other mentors had advised. It seems so simple and obvious to say that everyone has a unique opinion, but it's different to actually experience receiving contrary suggestions from smart, experienced practitioners who are trying to help you. As has been said many times elsewhere, it's important to apply the right advice to the right situation and to make one's own decisions. Aside from our own revisions, we additionally revised our survey 3 times based on mentor feedback. After the third time, we took a step back and realized that we had just been churning without making much real progress. What is really important is to understand the feedback mentors are offering and the reasoning behind it. This knowledge can then be applied to the task at hand.
After this realization, we tweaked the survey one last time, and were satisfied that it would help gather the knowledge we sought. Once finally ready, we sent the survey out using Amazon's Mechanical Turk. This was highly effective and at about 5 cents per question, we filled our initial round of 100 responses in about 30 minutes. At this speed, we realized that we had overpaid, but all-in-all it wasn't too expensive anyways. We sought an additional 100 responses and tried pricing them at about 3 cents per question. This worked as well, but took somewhere between 6x and 8x the amount of time to get the same number of responses.
While all of this survey-related learning was going on, two teammates did an amazing job hacking together a prototype through the course of the day using Twitter Bootstrap and CodeIgniter. They actually got a functional site up an running before we wrapped up for the night.
With all our feedback and a functional prototype, things are looking promising!
To start out, we took a close look at the various elements of our business model and identified the key assumptions that enabled the business. Based on these, we clarified what we wanted to learn from our study, came up with a set of questions, and created a Google Form to capture the information. As we went back over our initial set of questions, we felt they were too complicated and that the amount of mental energy spent answering them would cause participants to disengage before completing the survey.
After modifying the surveys, we got feedback from the Startup Weekend mentors. We spent some one-on-one time with them walking through the survey and looking for feedback on the questions that were being asked. Interestingly, it was difficult to get this kind of feedback because we found that once someone started reading through the survey, they'd jump into responding to it and it took significant focus to keep the conversation on track and ferret out opinions of the positives and negatives about the questions and structure of the survey itself.
Here's a big lesson we learned. Every mentor we spoke with gave different opinions, frequently with advice that was contradictory to what other mentors had advised. It seems so simple and obvious to say that everyone has a unique opinion, but it's different to actually experience receiving contrary suggestions from smart, experienced practitioners who are trying to help you. As has been said many times elsewhere, it's important to apply the right advice to the right situation and to make one's own decisions. Aside from our own revisions, we additionally revised our survey 3 times based on mentor feedback. After the third time, we took a step back and realized that we had just been churning without making much real progress. What is really important is to understand the feedback mentors are offering and the reasoning behind it. This knowledge can then be applied to the task at hand.
After this realization, we tweaked the survey one last time, and were satisfied that it would help gather the knowledge we sought. Once finally ready, we sent the survey out using Amazon's Mechanical Turk. This was highly effective and at about 5 cents per question, we filled our initial round of 100 responses in about 30 minutes. At this speed, we realized that we had overpaid, but all-in-all it wasn't too expensive anyways. We sought an additional 100 responses and tried pricing them at about 3 cents per question. This worked as well, but took somewhere between 6x and 8x the amount of time to get the same number of responses.
While all of this survey-related learning was going on, two teammates did an amazing job hacking together a prototype through the course of the day using Twitter Bootstrap and CodeIgniter. They actually got a functional site up an running before we wrapped up for the night.
With all our feedback and a functional prototype, things are looking promising!
Saturday, May 19, 2012
Startup Weekend Seattle Day 1
I'm back at Startup Weekend again! This is my third event and as always, I'm super excited.
Having been to a few events in the past and being moderately well tuned into the startup community, I came into this event seeing a lot of familiar faces. As I got to meet a number of the participants, I was surprised to find that perhaps up to 50% of them work at Microsoft. In general, this wouldn't be a surprise around the Puget Sounds area, but when it comes to startup events, including the last two Startup Weekends I attended, I typically feel like the number is closer to somewhere between 10% and 20%. There probably isn't a lot to read into in that, but who knows.
As usual, I pitched and idea, but this time I only got two votes, one of which was mine. The problem I wanted to solve was the difficulty in determining whether a group of people are likely to work well together. My initial idea was to create a tool that could tell a person how well they'd fit in a particular team and for the team, how well the incoming person would fit them. It's just too hard to tell what it's like working with a group of people until you've actually worked with them. In general, the ideas that got most votes seemed to be the ones that addressed problems a lot of people in the room faced, were using exciting new technologies, built off of popular trends, or where the presenter had some wacky idea and did a great job presenting it.
After my idea was removed from the selection process, I connected with team whose idea was "10pictures," a product that showed 10 pictures from a person in the highest definition possible and as large as possible. I felt like there was a lot of potential in the possibility of it becoming a social platform and with the Twitter and Facebook overload was excited about the constraint on content. Aside from that, the team lead was a pretty cool guy, who seemed like he'd be fun to work with.
As the team filled out, it grew to over 10 people. The team members generally had strong opinions of how the product should look, overconfidence in what they could achieve in the course of the weekend, and were completely focused on the product vision rather than the business. I imagine they'll build something cool over the course of the weekend, but it's not the experience I'm looking for. It largely reminded me of my experience at the first Startup Weekend I attended. I learned a lot from that experience, but wouldn't repeat it.
As I grew increasingly concerned with my fit on the team, I decided to go check out some of the other teams around the room. I decided to focus on finding out what some of the smaller teams were working on. I quickly synced up with a team of four, comprised of people I had already been interested in collaborating with. As I talked with them, I become really comfortable and found that I meshed really well with them. The idea they were working on was pitched as a site where people could submit startup ideas and vote on them. Based on the pitch and the large amount of potential competition in the space, I wasn't terribly excited about the idea at first. What really sold me though was the awesome team. These guys were really easy to talk to, were already learning from one another, and had already started making some progress on the idea. Regardless of whether the the idea turns into something that might work as a business, I figured it would probably be a fun thing to work on.
After discussing the business model a bit, I felt like the ideas was more interesting and had some potential. I'm really looking forward to getting to know the people on this team better and building something with them this weekend!
Having been to a few events in the past and being moderately well tuned into the startup community, I came into this event seeing a lot of familiar faces. As I got to meet a number of the participants, I was surprised to find that perhaps up to 50% of them work at Microsoft. In general, this wouldn't be a surprise around the Puget Sounds area, but when it comes to startup events, including the last two Startup Weekends I attended, I typically feel like the number is closer to somewhere between 10% and 20%. There probably isn't a lot to read into in that, but who knows.
As usual, I pitched and idea, but this time I only got two votes, one of which was mine. The problem I wanted to solve was the difficulty in determining whether a group of people are likely to work well together. My initial idea was to create a tool that could tell a person how well they'd fit in a particular team and for the team, how well the incoming person would fit them. It's just too hard to tell what it's like working with a group of people until you've actually worked with them. In general, the ideas that got most votes seemed to be the ones that addressed problems a lot of people in the room faced, were using exciting new technologies, built off of popular trends, or where the presenter had some wacky idea and did a great job presenting it.
After my idea was removed from the selection process, I connected with team whose idea was "10pictures," a product that showed 10 pictures from a person in the highest definition possible and as large as possible. I felt like there was a lot of potential in the possibility of it becoming a social platform and with the Twitter and Facebook overload was excited about the constraint on content. Aside from that, the team lead was a pretty cool guy, who seemed like he'd be fun to work with.
As the team filled out, it grew to over 10 people. The team members generally had strong opinions of how the product should look, overconfidence in what they could achieve in the course of the weekend, and were completely focused on the product vision rather than the business. I imagine they'll build something cool over the course of the weekend, but it's not the experience I'm looking for. It largely reminded me of my experience at the first Startup Weekend I attended. I learned a lot from that experience, but wouldn't repeat it.
As I grew increasingly concerned with my fit on the team, I decided to go check out some of the other teams around the room. I decided to focus on finding out what some of the smaller teams were working on. I quickly synced up with a team of four, comprised of people I had already been interested in collaborating with. As I talked with them, I become really comfortable and found that I meshed really well with them. The idea they were working on was pitched as a site where people could submit startup ideas and vote on them. Based on the pitch and the large amount of potential competition in the space, I wasn't terribly excited about the idea at first. What really sold me though was the awesome team. These guys were really easy to talk to, were already learning from one another, and had already started making some progress on the idea. Regardless of whether the the idea turns into something that might work as a business, I figured it would probably be a fun thing to work on.
After discussing the business model a bit, I felt like the ideas was more interesting and had some potential. I'm really looking forward to getting to know the people on this team better and building something with them this weekend!
Monday, April 30, 2012
Seattle Government Startup Weekend
This weekend was another Startup Weekend. This time, the event had a government theme. The idea was to build a company that would rely on government datasets and serve the community well.
When I arrived Friday evening, there were a few people I recognized, but many more who I didn't. I think the theme of this event drew a different group of people than I normally interact with at startup events. I was certainly pleased with the opportunity to meet and converse with new people. I was also pleasantly surprised to run into Bharat Shyam, who I had known from when I worked on Windows Azure. It turned out he was one of the judges of the event, which is fitting given his role as CTO of Washington state and his involvement with startups.
Soon enough, the idea pitches kicked off. As usual, lots of interesting ideas. I was really excited about some of them as I'd love to see more projects and services that benefit our communities. The idea I pitched was a Kickstarter for community projects where people could contribute money or volunteer hours to make something happen in their community. One of the funnier ideas, but intriguing none-the-less was a tracking system to see where someone's poo goes as it leaves the bathroom and travels through city infrastructure to processing and eventual disposal.
After the idea pitches, we had some time to mingle and vote on ideas. I walked around and talked to a few people whose ideas I liked and also to a few folks interested in my idea. Some of the ideas got votes right away, but mine was slow going. But in the end, it just barely made the cutoff in the top ideas and so it became one of the team projects.
During the mingling time, I focused my time on conversations with people who seemed collaborative. I tried to drop out of conversations quickly when people were only interested in talking about themselves (i.e. had no interest in listening), talked condescendingly of others, or seemed acerbic. This seems to have paid off because once team formation happened, I was really fortunate to have collaborative people gather around the idea, wanting to work together. Another element that made me feel particularly lucky was to have 3 designers on the team.
The first night wrapped up with brainstorming. We all gathered around, discussed the problem and the idea and hacked at the idea until we felt we had a plausible business model (using the business model canvas). This team was seriously awesome to work with. Everyone got a long really well, where several other teams seemed to be having tension as early as the first night.
Saturday was a really full day. We got feedback from mentors and I ended up spending a large portion of my time putting a survey together. This was the first time I really worked on making a survey and found it more difficult than I had thought it would be. How does one come up with questions that won't lead the answerer's responses? How does one make sure the questions surface the information needed? How does one do all this and keep the survey short enough to avoid discouraging respondents from completing it? In retrospect, I made a number of mistakes, but here's what we ended up sending out (note that we selected the name "CivicRally" for our service):
In addition to surveying, I hit the streets to do in-person interviews. This was my first time doing this as well. Needless to say, I felt nervous and awkward walking up to random strangers to interview them. It admittedly got easier as I went on, but I still felt uneasy whenever people would turn me down or avoid eye contact and run away as I approached. But I ended up with some great feedback and even had two videos. Unfortunately, I can't post the videos since I didn't get verifiable consent to make them public, which I should have done for educational purposes. Next time, I'll try to do so.
On the final day, we started integrating everything and getting tons of feedback from mentors. Some of the people who really helped us refine our business model as well as our pitch deck were Carter Rabasa, a developer evangelist for Twilio, and Robi Ganguly, CEO at Apptentive. Twilio and Apptentive are really cool companies, by the way.
Our slide deck came together along with the prototype. Even on our highly collaborative team, there was a small amount of tension as the deadline drew close, but nothing tumultuous. Other teams, on the other hand had been blowing up all over the place. Some teams disbanded and didn't return after Saturday. Some teams were loudly arguing throughout the weekend. I was really glad about the great group of people I was working with.
Finally, we wrapped things up and pitches started. I was presenting our project, so had been rehearsing and getting feedback all afternoon. In the end, getting the feedback on the dry runs was key. The pitch went really well, and we all felt relieved and proud of our accomplishment. As the judges started asking questions, we were completely shocked when one said we had "accomplished more in a single weekend than what Code for America had in a year," which was followed by applause from the the entire audience. I didn't really know what to say, so I just replied with something that had been on my mind all weekend, "it was entirely because of this great team."
After a long deliberation, the judges came back and announced the winners. We came in third. While we were happy to have ranked, we were most excited about how well we had all worked together, all the learning we did, and what we had accomplished in a short time.
While I will not be continuing this project, several teammates expressed interest in continuing to work on it. You can check out the result here (only a prototype as of writing, but hopefully something more later): http://www.civicrally.org/.
When I arrived Friday evening, there were a few people I recognized, but many more who I didn't. I think the theme of this event drew a different group of people than I normally interact with at startup events. I was certainly pleased with the opportunity to meet and converse with new people. I was also pleasantly surprised to run into Bharat Shyam, who I had known from when I worked on Windows Azure. It turned out he was one of the judges of the event, which is fitting given his role as CTO of Washington state and his involvement with startups.
Soon enough, the idea pitches kicked off. As usual, lots of interesting ideas. I was really excited about some of them as I'd love to see more projects and services that benefit our communities. The idea I pitched was a Kickstarter for community projects where people could contribute money or volunteer hours to make something happen in their community. One of the funnier ideas, but intriguing none-the-less was a tracking system to see where someone's poo goes as it leaves the bathroom and travels through city infrastructure to processing and eventual disposal.
After the idea pitches, we had some time to mingle and vote on ideas. I walked around and talked to a few people whose ideas I liked and also to a few folks interested in my idea. Some of the ideas got votes right away, but mine was slow going. But in the end, it just barely made the cutoff in the top ideas and so it became one of the team projects.
During the mingling time, I focused my time on conversations with people who seemed collaborative. I tried to drop out of conversations quickly when people were only interested in talking about themselves (i.e. had no interest in listening), talked condescendingly of others, or seemed acerbic. This seems to have paid off because once team formation happened, I was really fortunate to have collaborative people gather around the idea, wanting to work together. Another element that made me feel particularly lucky was to have 3 designers on the team.
The first night wrapped up with brainstorming. We all gathered around, discussed the problem and the idea and hacked at the idea until we felt we had a plausible business model (using the business model canvas). This team was seriously awesome to work with. Everyone got a long really well, where several other teams seemed to be having tension as early as the first night.
Saturday was a really full day. We got feedback from mentors and I ended up spending a large portion of my time putting a survey together. This was the first time I really worked on making a survey and found it more difficult than I had thought it would be. How does one come up with questions that won't lead the answerer's responses? How does one make sure the questions surface the information needed? How does one do all this and keep the survey short enough to avoid discouraging respondents from completing it? In retrospect, I made a number of mistakes, but here's what we ended up sending out (note that we selected the name "CivicRally" for our service):
- Would you be interested in using a service like CivicRally?
- How often do you do volunteer work?
- When you volunteer your time, what type of organization you volunteer with most often?
- If you were to volunteer your time, which would your top preference be as to the community your effort supports?
- If it were easier to find out about community projects near your neighborhood, how likely would you be to volunteer for those?
- Is there a project you would like to see happen in your neighborhood?
- If you have a project in mind, please provide a one-sentence description.
- If you have a project in mind, how much funding would it require?
- If there was a way to create, share, and support local community projects, would you submit projects? Contribute time to projects? Contribute money to projects?
- Would you feel more inclined to start local community projects if it was easier to get support for the project?
- How would you prefer to create, discover, and sign up to support community projects?
- When you donate money, what type of organization you donate to most often?
- If you were to donate money, which would your top preference be as to the community your donation supports?
- If your neighborhood had a score indicating the level of community engagement, would you contribute money or volunteer time to increase the score?
- Now that you've thought about the other questions, do you think you'd use a service like CivicRally?
- Approximately what percentage of your friends and family do you think would use a service like CivicRally?
- Which social media networks, if any, would you use to tell friends and family about CivicRally projects?
- If you started a community project with CivicRally, would you ask others who had not joined CivicRally to sign up?
- Age?
- Gender?
- Home zip code?
- Please provide your email if you would like to hear more about CivicRally later.
In addition to surveying, I hit the streets to do in-person interviews. This was my first time doing this as well. Needless to say, I felt nervous and awkward walking up to random strangers to interview them. It admittedly got easier as I went on, but I still felt uneasy whenever people would turn me down or avoid eye contact and run away as I approached. But I ended up with some great feedback and even had two videos. Unfortunately, I can't post the videos since I didn't get verifiable consent to make them public, which I should have done for educational purposes. Next time, I'll try to do so.
On the final day, we started integrating everything and getting tons of feedback from mentors. Some of the people who really helped us refine our business model as well as our pitch deck were Carter Rabasa, a developer evangelist for Twilio, and Robi Ganguly, CEO at Apptentive. Twilio and Apptentive are really cool companies, by the way.
Our slide deck came together along with the prototype. Even on our highly collaborative team, there was a small amount of tension as the deadline drew close, but nothing tumultuous. Other teams, on the other hand had been blowing up all over the place. Some teams disbanded and didn't return after Saturday. Some teams were loudly arguing throughout the weekend. I was really glad about the great group of people I was working with.
Finally, we wrapped things up and pitches started. I was presenting our project, so had been rehearsing and getting feedback all afternoon. In the end, getting the feedback on the dry runs was key. The pitch went really well, and we all felt relieved and proud of our accomplishment. As the judges started asking questions, we were completely shocked when one said we had "accomplished more in a single weekend than what Code for America had in a year," which was followed by applause from the the entire audience. I didn't really know what to say, so I just replied with something that had been on my mind all weekend, "it was entirely because of this great team."
After a long deliberation, the judges came back and announced the winners. We came in third. While we were happy to have ranked, we were most excited about how well we had all worked together, all the learning we did, and what we had accomplished in a short time.
While I will not be continuing this project, several teammates expressed interest in continuing to work on it. You can check out the result here (only a prototype as of writing, but hopefully something more later): http://www.civicrally.org/.
Saturday, April 14, 2012
What Comes First, the Team or the Idea?
In the context of entrepreneurship, an idea is a set of assumptions that appear to have the potential to be turned into a successful business. Recently, several colleagues and I were discussing whether coming up with a great idea or assembling a great team is the first step in starting a company. Personally, I believe deeply in the power of teamwork and the concept of getting the right people on the bus first (and making sure they're sitting in the right seats). And yet, the question of whether the idea or the team comes first presents something of a catch-22. If we start with an idea, it's incredibly difficult to find the perfect team for that idea. In fact, we might not even have a place on the perfect team. But if we don't have an idea, it can be incredibly difficult to recruit teammates.
The various popular sayings about the (lack of) value of business ideas hold some merit even though they aren't axiomatic truths. For example: ideas are a dime-a-dozen and don't fall in love with your idea. Although there may be some cases of people who change the world through stubborn resolve, I think they are rare. I believe it is much more effective and productive to seek feedback and apply it to your situation in an intelligent way. We might analogize putting all of our energy into a single, immutable idea with putting all of our money on a single horse in a race with a million horses. If the rules of the race allowed us to change our bet as the race progresses, why wouldn't we take advantage of that?
There are also varying opinions about keeping our ideas locked up so no one steals them. Annecdotally, the general recommendation from those with experience seems to be to share our idea with as many people as we can. That's how we get feedback and identify issues we might otherwise miss as individuals. There is a saying about keeping equity to one's self that I think applies very well to the concept of ideas: "Equity is (ideas are) like shit. Hoard it and you'll end up with a great big pile of shit. Spread it around and amazing things happen."
This brings us to consideration of the relationships between ideas. How do we define the boundaries between ideas? There are numerous elements of a business idea, which from a high level are well-captured in the business model canvas, and there are innumerable details. Clearly, any two ideas are connected by an infinite number of paths paved with consecutive tweaks to the details of the ideas. Defining the distinction between ideas, then, is like the old philosophical question that asks, "at what point does a boat become a different boat if we gradually replace each plank, one-by-one?" This brings us back to the cautionary note on not falling in love with our idea. If one of the planks is rotting, we have to be willing to replace it or risk sinking the entire boat. Sometimes this happens repeatedly until the boat is quite different from what we started with.
So how does the team fit into all of this? Teammates contribute to making prudent judgments about when to bet on which horse, keeping the boat in good repair, and making sure we don't end up with a pile of shit. The question remains of how we assemble the team.
Given that change is a certainty, it's important to keep our destination in mind. Focusing only on the immediate path causes us to get stuck when we hit a road block. Having a team with an eye on the goal is having a team that will adapt to change, while continuing to move in the right direction. It means having a team that will not fall apart when we inevitably hit rough patches.
What all of this leads up to is that we need to change the way we think. Let's stop focusing on "killer ideas" and instead start talking about our goals and how we're going to change the world. When we tell someone about our vision for the future, they're likely to offer up ideas about how to make it a reality. If they do, that's great - we've found a potential partner. Of course, we need to make sure that our team's values are aligned and that our personalities mesh, but focusing on goals is good way to find one another in the first place.
Now back to ideas. Ideas are hypotheses. They are just assumptions about how we might achieve our goals. They are meant to be tested and modified as we learn. A solid team with strong leadership will generate good ideas and go through the necessary steps to test and refine them. In the end, I suppose the question of whether the team or the idea comes first is misgiving. The answer is that goals come first, then, if possible, the team, then numerous iterations of ideas.
The various popular sayings about the (lack of) value of business ideas hold some merit even though they aren't axiomatic truths. For example: ideas are a dime-a-dozen and don't fall in love with your idea. Although there may be some cases of people who change the world through stubborn resolve, I think they are rare. I believe it is much more effective and productive to seek feedback and apply it to your situation in an intelligent way. We might analogize putting all of our energy into a single, immutable idea with putting all of our money on a single horse in a race with a million horses. If the rules of the race allowed us to change our bet as the race progresses, why wouldn't we take advantage of that?
There are also varying opinions about keeping our ideas locked up so no one steals them. Annecdotally, the general recommendation from those with experience seems to be to share our idea with as many people as we can. That's how we get feedback and identify issues we might otherwise miss as individuals. There is a saying about keeping equity to one's self that I think applies very well to the concept of ideas: "Equity is (ideas are) like shit. Hoard it and you'll end up with a great big pile of shit. Spread it around and amazing things happen."
This brings us to consideration of the relationships between ideas. How do we define the boundaries between ideas? There are numerous elements of a business idea, which from a high level are well-captured in the business model canvas, and there are innumerable details. Clearly, any two ideas are connected by an infinite number of paths paved with consecutive tweaks to the details of the ideas. Defining the distinction between ideas, then, is like the old philosophical question that asks, "at what point does a boat become a different boat if we gradually replace each plank, one-by-one?" This brings us back to the cautionary note on not falling in love with our idea. If one of the planks is rotting, we have to be willing to replace it or risk sinking the entire boat. Sometimes this happens repeatedly until the boat is quite different from what we started with.
So how does the team fit into all of this? Teammates contribute to making prudent judgments about when to bet on which horse, keeping the boat in good repair, and making sure we don't end up with a pile of shit. The question remains of how we assemble the team.
Given that change is a certainty, it's important to keep our destination in mind. Focusing only on the immediate path causes us to get stuck when we hit a road block. Having a team with an eye on the goal is having a team that will adapt to change, while continuing to move in the right direction. It means having a team that will not fall apart when we inevitably hit rough patches.
What all of this leads up to is that we need to change the way we think. Let's stop focusing on "killer ideas" and instead start talking about our goals and how we're going to change the world. When we tell someone about our vision for the future, they're likely to offer up ideas about how to make it a reality. If they do, that's great - we've found a potential partner. Of course, we need to make sure that our team's values are aligned and that our personalities mesh, but focusing on goals is good way to find one another in the first place.
Now back to ideas. Ideas are hypotheses. They are just assumptions about how we might achieve our goals. They are meant to be tested and modified as we learn. A solid team with strong leadership will generate good ideas and go through the necessary steps to test and refine them. In the end, I suppose the question of whether the team or the idea comes first is misgiving. The answer is that goals come first, then, if possible, the team, then numerous iterations of ideas.
Sunday, March 25, 2012
Driving Your Own Agenda Leads to Failure
I've been on many teams in my lifetime. At work, in school, in social activities, etc. During recent reflection on past successes and failures, I noticed that among cases of failure, it is common for team members, or a key team leader, to be focused on their own agenda. As I thought about this observation more, I came to the conclusion that when someone drives their own agenda, whatever they're working on is highly likely to fail.
This hypothesis sounds like an over-generalization. But let's clarify what is meant by "driving one's own agenda". This statement refers to situations in which one is so focused on their personal goals that certain realities of the environment in which they are operating fall the periphery of their view. To take a simple example, consider someone who wants a promotion. Their singular focus is on getting that reward. I purposely use the term "getting" because when the focus is on the promotion itself, it devalues the act of earning it. As focus on the promotion becomes sharper and sharper, everything else becomes obscured.
So why do I believe this behavior is highly likely to lead to failure? As I mulled over the the failures I've been through, I considered them in this context and asked myself, "isn't focus a good thing?" The answer is clearly yes. Focusing on a small set of goals and removing distractions is a powerful technique in achieving success; we've all heard the saying "do one thing and do it well". Wasn't focus one of Steve Jobs' (RIP) techniques for success? This is all true and good, but the problems start when one ignores the vast web of interconnections that render our actions inalienable.
To be successful, it is important to understand one's relationship with fellow workers and communal goals. It is important to understand how the different actors affect the system. While certain actions are isolated, others have direct and obvious impact, and still others reverberate through the web in subtle ways. And we can't forget that we are not the only party taking action. We need to understand the structure of the web and how our goals play into it. If we are so caught up in driving our own agenda that we can't see beyond the immediate impact of our behaviors, we are highly likely to fail since we miss the broader dynamics at play. Elaborating on our example, if we are pursuing a promotion with tunnel vision, we may miss the fact that the organization we are part of needs to have the profits to fund the promotion. As we invest our energy into standing out from our peers and gaining influence on key organizational decision makers, we divest elsewhere, perhaps reducing the overall profit-earning capacity of the organization. Thus, our singular focus on our goal not only contributes to our failure to achieve it, but also negatively impacts those depending on us.
The thing to remember is to be aware of the complex web of interrelationships and how the different pieces influence one another. For success, understand the best way to invest your energy in this holistic context. From my experience, this usually means driving community goals rather than individual agendas.
This hypothesis sounds like an over-generalization. But let's clarify what is meant by "driving one's own agenda". This statement refers to situations in which one is so focused on their personal goals that certain realities of the environment in which they are operating fall the periphery of their view. To take a simple example, consider someone who wants a promotion. Their singular focus is on getting that reward. I purposely use the term "getting" because when the focus is on the promotion itself, it devalues the act of earning it. As focus on the promotion becomes sharper and sharper, everything else becomes obscured.
So why do I believe this behavior is highly likely to lead to failure? As I mulled over the the failures I've been through, I considered them in this context and asked myself, "isn't focus a good thing?" The answer is clearly yes. Focusing on a small set of goals and removing distractions is a powerful technique in achieving success; we've all heard the saying "do one thing and do it well". Wasn't focus one of Steve Jobs' (RIP) techniques for success? This is all true and good, but the problems start when one ignores the vast web of interconnections that render our actions inalienable.
To be successful, it is important to understand one's relationship with fellow workers and communal goals. It is important to understand how the different actors affect the system. While certain actions are isolated, others have direct and obvious impact, and still others reverberate through the web in subtle ways. And we can't forget that we are not the only party taking action. We need to understand the structure of the web and how our goals play into it. If we are so caught up in driving our own agenda that we can't see beyond the immediate impact of our behaviors, we are highly likely to fail since we miss the broader dynamics at play. Elaborating on our example, if we are pursuing a promotion with tunnel vision, we may miss the fact that the organization we are part of needs to have the profits to fund the promotion. As we invest our energy into standing out from our peers and gaining influence on key organizational decision makers, we divest elsewhere, perhaps reducing the overall profit-earning capacity of the organization. Thus, our singular focus on our goal not only contributes to our failure to achieve it, but also negatively impacts those depending on us.
The thing to remember is to be aware of the complex web of interrelationships and how the different pieces influence one another. For success, understand the best way to invest your energy in this holistic context. From my experience, this usually means driving community goals rather than individual agendas.
Wednesday, February 29, 2012
Who deserves credit for Lean Startup?
With all the excitement about Lean Startup (Eric Ries has made comments with concern about over-hype), it's easy to miss other important works. In particular, I have just finished reading The Innovator's Dilemma by Clayton Christensen, which was first published in 1997. While reading, I was awestruck by the concepts Christensen brings to light. But more on the thesis and general topics of the book at a later date.
What I want to point out is that every entrepreneur should read this book. A lot of important concepts Steve Blank elaborates on in The Four Steps to the Epiphany (2004) and Eric Ries simplified and popularized in The Lean Startup were already captured in The Innovator's Dilemma. In fact, Blank and Ries frequently recommend reading The Innovator's Dilemma. What Blank and Ries did was to help us understand the concepts, identify how they relate to our success as entrepreneurs, and give us a road map with tips and tools to use them.
A few excerpts from The Innovator's Dilemma will illustrate concepts very familiar to fans and practitioners of Lean Startup:
So aside from giving credit where it's due, what additional value comes from reading The Innovator's Dilemma? a general outcome is to understand what disruptive innovation is and its contrast to sustaining innovation. Readers will learn why entrepreneurs that develop disruptive offerings can compete and win against entrenched, well-funded competitors. People often talk about how startups have an advantage by being nimble and this book helps develop a definition of what it really means to be nimble and implicates how to strategize around that, turning it into a competitive advantage (against established players).
With the recent attention being given to the methods of Lean Startup, I want to recognize Christensen for identifying the concepts 15 years ago and at the same time thank Blank and Ries for developing them and spreading the practice. All are critical pieces that work together as part of the same puzzle. So if you haven't already done so, make a little space next to Blank and Ries on your Lean Startup shrine for Christensen.
Who else deserves recognition for identifying and publishing these concepts prior to Christensen?
What I want to point out is that every entrepreneur should read this book. A lot of important concepts Steve Blank elaborates on in The Four Steps to the Epiphany (2004) and Eric Ries simplified and popularized in The Lean Startup were already captured in The Innovator's Dilemma. In fact, Blank and Ries frequently recommend reading The Innovator's Dilemma. What Blank and Ries did was to help us understand the concepts, identify how they relate to our success as entrepreneurs, and give us a road map with tips and tools to use them.
A few excerpts from The Innovator's Dilemma will illustrate concepts very familiar to fans and practitioners of Lean Startup:
- Research has shown, in fact, that the vast majority of successful new business ventures abandoned their original business strategies when they began implementing their initial plans and learned what would and would not work in the market... Guessing the right strategy at the outset isn't nearly as important to success as conserving enough resources... so that new business initiatives get a second or third stab at getting it right. Christensen cites supporting research that goes as far back as 1992.
- But in disruptive situations, action must be taken before careful plans are made. Because much less can be known about what markets need or how large they can become, plans must serve a very different purpose. They must be plans for learning rather than plans for implementation... Discovery-driven planning, which requires managers to identify the assumptions upon which their business plans or aspirations are based, works well in addressing disruptive technologies. Here he references work from 1995.
- Moore suggests that products are initially used by innovators and early adopters in an industry - customers who base their choice solely on the product's functionality... Moore observes that markets then expand dramatically after the demand for functionality in the mainstream market has been met... A third wave of growth occurs... pulling in the late majority customers. Note that Crossing the Chasm was published all the way back in 1991.
- Although we don't have a clue about where the market is, the one thing we know for certain is that it isn't an established... market segment.
- But, although we may target this market first, there's a high probability that our initial concept will prove wrong. So we've got to get the first models done fast and on a shoestring - leaving ample budget to get it right once feedback from the market starts coming in.
So aside from giving credit where it's due, what additional value comes from reading The Innovator's Dilemma? a general outcome is to understand what disruptive innovation is and its contrast to sustaining innovation. Readers will learn why entrepreneurs that develop disruptive offerings can compete and win against entrenched, well-funded competitors. People often talk about how startups have an advantage by being nimble and this book helps develop a definition of what it really means to be nimble and implicates how to strategize around that, turning it into a competitive advantage (against established players).
With the recent attention being given to the methods of Lean Startup, I want to recognize Christensen for identifying the concepts 15 years ago and at the same time thank Blank and Ries for developing them and spreading the practice. All are critical pieces that work together as part of the same puzzle. So if you haven't already done so, make a little space next to Blank and Ries on your Lean Startup shrine for Christensen.
Who else deserves recognition for identifying and publishing these concepts prior to Christensen?
Subscribe to:
Posts (Atom)