Stair Step Growth

Problem Development Learning: Dont explain what your startup does to a “layperson”

Most entrepreneurs following the Lean Startup Methodology or the Customer development methodology will tell you that it never really works in a linear, sequential fashion, neither does it follow the prescribed set of steps.

The primary reasons are either because you end up getting some feedback or learning during the entire process that changes your perspective quickly or get distracted.

I had a chance to talk to 3 entrepreneurs last week, who had all shut down their startups. One of them got a job at Facebook, after raising money from VC’s (tier 1 VC’s at that), another has started on a new venture and the third is going back to his previous role at a large company.

All 3 of them had spent upwards of 6 months and the most was 18 months in their startup. Surprisingly, none of them mentioned “lack of ability to raise more cash” as their reason for failure.

They all mentioned the challenges of “customer development”.

Stair Step Growth

Stair Step Growth

The startup development process comprises of 5 steps – problem development, customer development, prototype development, product development and revenue development.

I am showing these in a stair step approach, which suggests a sequential method, but I fully understand it is rarely so.

Problem development is a relatively new phenomenon, and your goal is to do a good enough job, fine tuning and understanding the customer problem in detail.

What I have found that in the quest to explain “what is your story” to a layperson, most entrepreneurs end up explaining the problem their solution solves, not the customers real pain point.

The biggest challenge for you the entrepreneur is to have the problem statement nailed in as great detail as possible when explaining it to your product and development teams. Else the “high level” problem statements, which you will use with customers or investors will result in poorly thought out solutions.

There are choices that you will have to make daily and hourly about product, experiences, features and direction of your product. In the absence of having a detailed set of problem statements – which constitutes the problem development step, most of these choices will be sub optimal.

Focus on problem development in conjunction with customer development for best results.

Winning at Hackathons

Are hackathons a great resource to build your initial prototype?

Having attended, participated and judged over 50 hackathons in the last 3 years, I am a huge fan of the process, the energy and motivation that goes into making one happen.

My first hackathon was in San Francisco 2007 at the IPhone Dev Camp in San Francisco at the Adobe offices. I was new to iOS programming and wanted to learn the process to build apps. I was largely interested in learning what it took to build an app, not necessarily to build a company.

At this event there were about 40-50 people who gathered on a Friday. Most (over 60%) were first time iOS developers, who knew HTML, some php and Java, but had not build for the phone at all.

For those who have never been to a hackathon before, they tend to follow a fairly simple format. Developers, designers and engineers get together for 50-60 hours (Friday to Sunday) and come with some skills, ideas and passion to build something useful over the weekend.

In most hackathons there are non-developers as well who come to “pitch ideas” they want to work on and are looking for a team. If you are not a developer, I’d still highly encourage you to go to a hackathon and use it as an opportunity to learn to code.

More than to look for engineers who can help you build the product or prototype, I’d say the biggest value from a hackathon for non-developers is to reinforce the online learning at places such as Udemy, Courseera and other resources.

I have met several startup teams whose founders have met at hackathons.

If you are a non-developer, the tendency at the hackathon is to pitch an idea (you are given time to do that during the first day) and try to recruit engineers and designers to help.

I dont think that’s a great use of time.

If you are only the “idea” person who can “hustle”, you end up attracting a set of people who are non-developers themselves. The best way to gain the confidence of a good team of developers and engineers is to appreciate the work they do and find ways to help them, even if it is a small part of the work.

Even starting to build wireframes, some basic Photoshop skills or HTML / CSS is more valuable than just “talking” about your idea and showing others how “passionate” you are about your idea.

The art and science behind getting a great team to help is to be prepared with as much information that sends “signals” to others that you are likely to win the hackathon.

Ideas rarely win hackathons, functional prototypes with a great story and pitch do.

If you can show that you have made great progress with your idea over several iterations and need help to start getting further along with the product or prototype, you will be able to attract a much better team.

To answer the question: “Are hackathons a great place to build your prototype”? Absolutely yes, if you are well prepared. People that have prototypes built at hackathons are those that have wireframes completed, the customer development done and also have made some progress towards their mockups.

5 Killer Skills for Non technical Founders

The 5 most important skills you need to master if you are a non-technical (developer) startup cofounder

Over the last few years, I have met and connected with over 55% of founders who are non-technical (actually most are technical, but they are not developers). The standard advice I would give them was their role was to acquire users (or customers):

A plan to acquire, nurture and grow users (customers) with as little money as possible.

After spending time thinking about this over the last few days, I think there is more than just user acquisition that non-technical founders can help the startup with. There are 7 skills (in no ordered priority) that I think will help the company tremendously.

5 Killer Skills for Non technical Founders

5 Killer Skills for Non technical Founders

1. User acquisition and customer development. Getting early traction is critical and in most cases more important than most other things at your startup. While it is becoming easier to build and create apps and websites, getting early users who can give you feedback on the product and become fans and champions is hard. Understanding user behavior and motivations, spending time learning about how they would use the product is critical.

2. Generating shareable content (writing great headlines, producing videos, podcasting, etc.). While content is king, the more important skill is writing killer headlines. You need good content, but without great headlines, great content is useless. Getting awareness for your startup or product without the money early on to spend on advertising, is crucial to early traction and building your brand.

3. Learning about techniques to generate awareness (building connections with Press, Bloggers and Influencers) among customers and users. Besides generating content, figuring out ways to get more of your customers to share the product with new customers (increasing the virality coefficient) is a key skill. The best way to generate awareness among potential customers is to get existing customers to say good things about the product. The next step is getting them to share their experiences with others.

4. Cultivating and managing relationships with a strong potential investor pool. Generating enough inbound inquiries because you built a great product and got good press and coverage around it is one of the top things you need to be skilled at doing. Ensuring that you have a good product is half the battle. The next step is to get customers. To help you scale, would then require an early set of investors. Building investor relationships, targeting the right early stage funding sources is a crucial skill.

5. Signing up beta customers, creating activity flows and user models, building the wireframes. Even if you are not technical, you can build wireframes using standard tools to share the concept with users during your customer development phase. If all you have are PowerPoint skills, use them. If you understand the domain and can build the customer use scenarios, I’d build those.

There are some other “tactical” items that fall into the purview of the non-developer cofounder including the skills to negotiate contracts, get as many “free” services as possible, apply to many freely available programs such as accelerators, pitch showcases, etc., but those are secondary.

Over the next few days I will outline each of these in detail so I can help non-technical cofounders.

If you are considering a startup blog, focus on “more” insights, not a “better” narrative

Over the last 4 months as many of you have noticed I have been writing a blog post daily. That’s resulted in 120+ blog posts and a few insights on what I learned by blogging daily.

There are many things I have learned about the writing process and very little about building a strong readership base. The number one thing that’s changed over the last few years is that most people seem to care about the number of unique new things (insights) they have access to and reducing the amount of time spent gaining those insights.

I guess that’s not “new” news or insightful, but it is the explanation for the success of tweetstorms.

Made popular by Marc Andreessen, who had a blog a few years ago and quite possibly figured out this inadvertently or by design.

Here is what I mean by concentrate on more but smaller pieces of insights vs. One big insight but with a great narrative.

Thanks to the mobile phone (largely screen size) and twitter, there is so little time for people to read long form articles that the number of long form pieces being read (and also the number of books) is reducing dramatically.

At the same time, people prefer to read 10 individual, standalone sentences that are 140 characters or less than read one big paragraph with 10 lines or 1400 characters.

Giving a lot of context, adding many superfluous words is what a lot of writers do. The readers, though seem to have no more time or patience for it.

The implications for those wanting to make money writing a book (non fiction) or a blog are pretty big.

Here are some examples of things that work.

1. Lists – take any article you are planning to write and make it a list with some visuals. That works.

2. Instead of long paragraphs, with 5-7 sentences and over 70-100 words, focus on writing 1 sentence.

3. Video or Podcast: Focus on getting your content in an audio or video format with a 5 min solution instead of writing. The time to read an entire 750 word blog post might be 5-6 minutes and it may be the same amount of time to read 20 tweets, but readers seem to prefer the latter.

The other thing that works is attention grabbing content shock.

The real disruption from the cloud is yet to come for Indian IT services companies

About 60% of revenue for software vendors (for businesses) is custom and 40% ($135 Billion, 2014) of it is packaged. Over the last 10 years, the trend has shifted from custom  to packaged (Saas). With the rise of cloud deployment the time to install, upgrade and customize software has reduced dramatically as well. Finally with cloud deployments, the number of people needed to manage servers, patch and upgrade systems has dramatically gone down.

These 3 main factors are the reasons why there is a lesser need for software developers, system administrators and systems integrators.

The WSJ has a piece on Indian Outsourcing firms changing direction thanks to cloud. The piece talks about how larger customers of Indian outsourcing firms are no longer signing up for large contracts to outsource their work.

The Indian outsourcing market has grown over the last 20 years from less than $1 Billion to over $120 Billion in 2014. There were 5 major drivers of this work as large IT organizations moved their back office work to India.

1. Support and maintenance of existing custom software. – 30% of revenues

2. Customization, deployment and installation of package software (SAP, Oracle, Siebel, etc.) – 25%

3. Remote managed services – managing, hosting, upgrading and patching systems – 20%

4. Business process outsourcing such as legal, administrative, and finance and accounting – 15%

5. Call center services and customer support – 10%.

In the next 10 years, there are expected to be over 10,000 SaaS companies catering to needs of most all sub segments of the market and niche user spaces.

Thanks to SaaS, the need for custom software is going down.

The rise of cloud-deployed SaaS also means fewer companies need as many people to upgrade or “deploy” packaged software. Customization is still needed, but much less so.

The rise of IaaS (Infrastructure as a Service) means the need for remote managed services is also reducing.

Many of the call center processes are being automated with machine learning, Artificial intelligence and data science. Which means that the need for call center services is reducing but that’s also because the customer experience was poor compared to having folks in the US support customers locally.

What does this mean for Indian IT outsourcing? Will they evolve or perish?

The large companies will try to morph and grow (many are struggling to do so), into full service providers with a focus on consulting (which needs fewer, but higher-end resources), data science and cloud managed hosting services.

Many of the resources will need to be retrained and redeployed.

The real disruption in IT outsourcing to India over the next 10 years is coming. The challenge that’s being faced by these companies is to figure out how to disrupt the larger systems integration firms that are migrating to consulting and complete IT outsourcing as opposed to software development, maintenance and monitoring.

5 strategic items to consider before you get acqui-hired #napkinStage

In the last 3 years at Microsoft Ventures, 7 teams have been “acqui-hired”. 2 were from India, 5 in the US. I had a chance to be up close and see the action, the challenges, the frustration, the joy and the sigh of relief that the entrepreneurs face with these deals.

Acqui-hires fall into 2 buckets – those that save face and those that are incrementally progressive.

While many of the acqui-hires seem like a face-saving opportunity for the founders, they are pretty traumatic for the employees and almost always a poor deal for the angel investors, with exceptions.

The incrementally-progressive ones land the early employees great jobs in the new entity, provide a small return for the investors and allow the founders to get a small win under their belt.

I think about acqui-hires with the focus on the 3 main constituents – the early employees, the advisers and investors and finally the founders.

 

Acquihire Model and Strategy

Acquihire Model and Strategy

You could debate who comes first and who should be considered later, so this is only one model for thinking about this.

1. Return on Risk (ROR) for early employees. Most of your employees (if you hired great folks who were already in other great companies) have taken some form of risk to come and join your startup. Assuming that many left opportunities that were considered less risky than yours, I suspect they would expect a sufficient return on the risk taken. Most good employees, will get an offer from your acquirer, which, I think is the main reason why they are acquiring your company in the first place. The best way to give them a return on risk is to help them “true up” on their salaries they forwent.

2. Return on Time (ROT) for the first few hires. In most acqui-hires, I have seen that the acquiring company does not value the product / service that has been built, but instead likes the team. Building a new team who work well together takes time and energy, which is why they chose to acquire a team instead. A good way to help your early employees a return on their time spent (and you as well to hire, recruit and build the team) is typically via a “sign on bonus” for the entire team.

3. Return on Investment (ROI) for your early investors: If you take money, it should your responsibility to return it if you make some money. While many founders feel that angel investors fully know the risk they undertake when they invest in startups, the responsibility to return money does not go away when things dont work out. What I have found is that most founders will end up going back to being founders again and if you leave a trail of destruction or burn bridges when you do your first startup, it will get much harder to raise money for the next one. If you can help investors get as much money back or return their invested capital, then you will go a long way in terms of building credibility for your next venture.

4. Return on Equity (ROE) for advisers. Early advisers dont invest money, but typically their time. While you might feel less responsible towards them since “they did not lose money”, they did give you time, some connections, advice and mentorship, I think you should try and get some for of return for their Sweat Equity. I have seen one or two founders, taking a portion of their “earn out” to buy out the adviser shares that have been vested. You dont have to do this, but it does help.

5. Return on Opportunity (ROO) for founders. While most founders are relieved just with any exit (given that many acqui-hires were to save certain closure) I do think that founder return is important. If you do get an opportunity to get a good package of stock options and sign on bonus from your acquiring company, I’d highly recommend you negotiate for that.

I have found that in 4 of the 7 deals that happened, the acquiring company would have gladly paid an extra $100K – $250K just so the various parties involved would be “made whole”. In many cases the founders just did not ask since they were desperate to get the deal done.

My only suggestion to you as a founder is to ask if you can. If there is a good alignment with the acquiring company and they wish to keep all the employees for a longer time, they would gladly negotiate some more money to help make the deal more attractive to all parties.

The reason for the $100K to $250K number is simple. If your team is 3-5 people, the cost of hiring a team alone will be covered at those numbers. So, in most cases, it will be a win-win for the company.

Which type of pivot is the hardest for entrepreneurs?

If you have been working on your startup for any reasonable amount of time, you will learn quickly that the market and customer assumptions you make are quite different from reality in most cases. In some situations they might be relatively benign and still others they might take a complete change of focus and direction.

At the #napkinStage of the company, pivots are a lot easier to execute than at the later stages. Since the immediate impact is largely the time and effort spent on the idea, it tends to be easier to acknowledge, explain or work on.

In watching 14 entrepreneurs over the last 6 months, I have seen 5 companies pivot.

Types of Pivots

Types of Pivots

The hardest is the Market pivot – focusing on a completely different market than the one they focused on before – going from IoT startup to a data SaaS company. This type of pivot will take 18 or more months to execute. Learning about a new market is hard. Building relationships and understanding nuances of the landscape is even harder. It might seem easy since when you research on the Internet, but many markets are fairly opaque, till you spend more time learning about them.

The second hardest is the Customer type pivot – a company went from selling to consumers to selling to SMB with the same product. Changing the customer type or target customer is equally difficult. The hardest part is knowing and understanding the influence and decision making landscape if you are in B2B or to find the immediate value for the consumer if you are B2C.

The third hardest is the Customer problem pivot – one of the startups, realized, after talking to their target users that the problem more pressing was a different one and hence changed their product. If you already know your customer, but find out that the “latent” problem you perceived was different from the top 3 problems for your customer, then it is relatively less difficult to change course and pivot to the new problem. While communication with the internal team is still a challenge, these pivots tend to be able to execute faster.

The less harder pivot is the Business model pivot – a company went from charging on a SaaS monthly subscription model to a commission model on sales. By no means am I suggesting that a Business model pivot is easy. Having seen 2 companies of 14, just in the last 6 months, I think of all the other pivots, these are easier to execute and will likely take less time.

The first part of your problem is spotting the trend lines that help you understand when to pivot. The second (and likely more hard) part of your pivot is communicating – to your employees and founders, your customers, to potential and existing investors and to others who were involved – mentors, advisers, etc.