Wednesday, December 19, 2012

Document Your MVP for a Developer

I was talking with an early-stage founder who has a product vision and wants to get a Minimum Viable Product (MVP) built.  He is not a technical person, but is somewhat web savvy.  He wanted to get input from me on what he's doing, and he wants to begin to ask developers what it would take to build his product.  I asked some of the same questions I ask in my Free Startup CTO Consulting Sessions and then I get to a very common conversation:
MeDo you have specs?
FounderUmmm ... <embarrased look> ... what do you mean?
MeProduct definition, use cases, feature list, wireframes, comps, really whatever you have.
FounderUmm ... <still embarrassed> ... what format would you and the developer want that in? 
I'm never trying to embarrass someone.  I know how it feels.  It's the same as when I've created financial models and then have it reviewed by a hard-core CFO, sophisticated investor or similar kind of expert.  And in the case of defining mobile/web/software, there is even more variability in terms of form and format.
So, I promised this founder to do a post talking about how you go about create specifications of your MVP.

First Relax

imageBefore you begin reading all of the stuff below, it's going to be new, different, confusing.  You likely are writing your first one of these.  Don't stress over format.  Don't stress if you are doing it right. 
This should be an iterative process with advisors and customers providing feedback on the product. 
Conversations with a technical advisors or possible developers should be iterative. 
In fact, let me provide an important warning:
If you create these documents, don't have input from a technical resource, take it to a development shop and they provide you a price.  Go find a new technical resource. 
So, just get down what you can in a form that works for you.  I don't expect you to provide all of these things.  Part of what I like to find out is where you are relative to capturing these things.

Business Concept

The key first part of the conversation with a developer is having a good capture of the business more broadly.  The  business canvas model is a good short list.  Or you can have a pitch deck.   You might also have a business plan, marketing plan, financials, competitor analysis or other kinds of background document.
Ideally you are also able to say what you are really trying to prove to get to the next level.  For example, if you are trying to determine viral coefficient (see Startup Metrics), then the focus should be around those aspects of the MVP.  It's important to know where the business is today and what you are really trying to achieve.
Quite often these things get old quickly.  It's fine to send out documents that have older information.  Just make note of it in the document and/or in an email when you send it.  Seeing the evolution of thinking is not a bad thing.

Customer Development Notes

I'm assuming founders are having customer development conversations.  It would be great to get notes and summaries from these.  See also: 12 Tips for Early Customer Development Interviews, 12 tips for customer development, tips for customer development.

Prioritized User Stories

Define the customer problems and beginnings of the solution through user stories (see user stories, user story).  Prioritize these stories.

Product Feature List

Create a prioritized high level product feature list (see Product Backlog).  Make sure you look at 32 Questions Developers Should Ask a Startup Founder to spark possible additional features.  Make sure you keep focused on your key business drivers and prioritize the features aggressively based on those drivers.

Functional Details

For the higher priority features, begin to capture additional level of detail of those features particularly focusing on the behavior of the application.  See User Story is Worthless - Behavior is What We Need although you don't need your behavior description to be as formal as what is presented.  Really this begins to be a Functional Specification.  Developers don't need everything to be fully documented.  Rather are just looking for more detailed description of the features/functions.
Examples (these are going to be more detailed than you need to get to at this point):

Wireframes, Comps, Clickable Prototype

Create wireframes for a few key screens that sketch your concept using a tool like Balsamiq
Send across any graphic designs you currently have. 
If you happen to have a clickable prototype, that's great.  That's fairly uncommon.

Other Documentation

Here are other things you might be told about and try to capture:

Additional Resources

Here are a bunch of additional resources
You should definitely look at Steve Blank's book and review his blog.

Monday, December 10, 2012

Technical Advisors: Every Web/Mobile Startup Must Have One

I did a presentation recently for a graduate class from The Founder Institute around getting online/mobile products out the door.  I LOVED it because, the presenting part was over quickly and we got into specific issues that the founders had in terms of getting things built.  It was like having a bunch of mini-Free Startup CTO Consulting Sessions all in one room.  But what was interesting to me was that I found myself recommending that each of them should have a technical adviser.

imageWhy?  Roughly, they needed to make sure:
  • Specify the right things to be built. 
  • Third party products are used appropriately.
  • Structure development contracts appropriately or directing the in-house team appropriately.
  • Plan for past the initial MVP.
  • Review the code being built.
This is exactly the kind of thing I'm doing as a Part-Time CTO or Technical Advisor for startups.  It just didn't dawn on me how common this need is.  And it made me come to a new realization:
Every early-stage web/mobile/online startup should have at least one technical advisor, probably two.
There are two kinds of advisors that are commonly needed.

Strategic Technical Advisor

Look at the business and determine what's going to make sense from a development perspective in the short-term, longer-term.

They need to be able to know the key Questions Developers May Have Forgot to Ask a Startup Founder, figure out where/when/how to bring on development talent (Hiring Developers Before Product/Market Fit? , How to Hunt Programmers for Your Startup - A Field Guide), how to manage development resources (Startups and a Common Misunderstanding in Agile Software Development, Poor Software Developers - Pull the Plug Early, Symptoms of a Weak Development Team), choosing technical frameworks (Choosing a Programming Language and Framework for Your Startup), and other aspects of making broader choices about what will get developed, how it will be built, and making sure that you ultimately deliver the right stuff at the right time.

I was very worried for several startup in the room.  They were making some significant choices that were going to have lasting impact on their company.  Why do this without the right technical advisor?  Would you create contracts without an attorney? 

Tactical Technical Advisor

There's also a tactical level for technical advisors.  We are producing the right functionality, but is the code that's being produced the right product?  Is this something that's scalable and extensible?  This kind of advisor should be looking at the code on a fairly regular basis to make sure that the team is building the right thing.  This is important whether you are outsourcing or building it in-house.  If you are outsourcing, then this person will also be protecting you from issues like being able to access the source code and making sure can bring it in-house at a later time.  Do you really have control of the development?  If you don't have this kind of person and you are not personally looking at the code, then you don't really have control.

There are some technical advisors who can do both strategic and tactical, but its common to find a tactical advisor separately.

CTO Founder - Do they really still need a technical advisor?

I know relatively few people who are good at both a strategic and tactical level.  Most early-stage, in-house teams needs to be hands on developers, not strategic.  It's rare to find a person who is good at both strategic level thinking and is still a rock star, cranking out code.  Early-on, bring people on who can produce volume.  You can get strategy level on a part-time basis.  I've talked about this before in Startup CTO or Developer.  Is this person a CTO or a developer?  Likely they will have gaps in one or the other.  Get an advisor to help supplement where there are gaps.

By the way, do you know that most development teams use peer review of code to help ensure good development practices.  Who's doing that for your CTO?

Where Do I Find a Technical Advisor

You are looking for part-time people in these rolls so you often are finding people who already are employed somewhere else.  In Los Angeles, I have easy access to a bunch of potential strategic technical advisors through the LA CTO Forum.  If you need a strategic advisor, contact me and I will connect you with someone from the group.  Another avenue is looking for CTOs/VP Engineering via LinkedIn.  It's going to be a numbers game to find the right person that way, but still quite doable.

Tactical advisors are also going to be already developing or leading development full-time at a startup.  They will have the title Lead or Manager.  They should only be a year or two removed from full-time hands on.  Ideally they have experience with your full technology stack, but in some cases, having them learn about best practices will be necessary.


This is going to depend on the specifics of the work.  When advisors need to jump in and spend significant hours on a particular issue, then likely cash compensation is going to be required.  If it stays at a few hours per month, then using something like Founder Institute's FAST agreement probably makes sense.  Just make sure its clear what the expectations are going into any engagement.

Why Investors Should Demand This

I quite often get a call where a founder raised $150K of initial money and has spend $120K on in-house or outsourced development and the software is 90% done.  But they are having a tough time getting it all the way done.  As I mention in Symptoms of a Weak Development Team, the number one reason I get calls relates to an old software engineering adage:
The first 90% of a project takes 90% of the time.  The last 10% takes the other 90%.
In the case of these calls where the initial money has mostly been spent, it can be very tough to recover.  Most often the failure is both a result of the founder not doing the right things and because the developer over-promised and failed to ask the right questions.  Having a strategic and tactical advisor can greatly reduce the chance that this is going to happen.

What's funny is that once software has been built and you move from Seed to A or B round, I often get calls by investors about reviewing the existing product to see if it has reasonable quality and if the team is going to be able to continue to produce going forward.   Why a Seed level investor doesn't insist on a technical advisor, I don't know.

Bottom line - if you are an early-stage startup with online or mobile technology as part of your solution, you ABSOLUTELY NEED a technical advisor.

Monday, November 19, 2012

Find and Talk to other Startup Founders of Similar Startups

One of the recommendations I make all the time to startup founders, is to find other founders who have tackled similar problems as yours and talk to them about how they solved these problems.

As an example, I'm working with two sets of founders who are both going to be dealing with Getting Started with a Two-Sided Market Business - they are variants of two sided markets, but have similar characteristics.  They have both chosen to launch first in a particular geography.  Because their audiences are different, they will take very different approaches to how they do their geography specific launch strategy.

My suggestion to both of them is that they should talk to founders (or maybe early employees) who have launched startups with similar characteristics.   You should consider:

  • Audience
  • Product
  • Strategy
  • Business Model
  • Competitive Set

You probably can't talk to someone at a direct competitor (although ex employees may work), but it is generally easy to find parallel businesses.   Who has launched a similar kind of business?  Ideally they've launched these fairly recently.

So who has launched businesses with local focus initially?   Well, there are going to be a ton of these.  Come up with various ideas.  Ask around about others.  But let's just say you came up with Groupon as one of them.

First Stop CrunchBase

Here's the link to the Groupon Profile on Crunchbase.  Here's some interesting things I can find:


You can find Founders listed here.  Former people can be a wonderful source of information as well.  See below for tracking down these folks through LinkedIn.


Acquisitions and competitors can often yield startups that took similar approach to how they rolled out, had some success.  Worth looking through these for some interesting parallels.  Again look for founders.  And save names of of companies that match your criteria.

Second Stop LinkedIn

Advanced people search in LinkedIn is a beautiful thing.


In this case, I'm looking for:

  • Company - put in the related startup
  • Title - "founder" or "marketing" or nothing

You will come back with some very interesting folks.   My suggestion would be to not necessarily target Groupon itself, but more of the competitors and acquisitions.  In some cases, you can target people who were at one point at Groupon and now have founded something else.

Once you've found some people, now its time to reach out.  I've talked about this before in LinkedIn Conversations.  Here are the keys:

  • Show that you are real and serious.  Funded is a good word to use.  As is being specific about your issue.
  • Be brief.
  • Ask for a brief conversation.
  • Don't use the words "pick your brain"

As an example:

Hi Joe,

I'm the founder of an pre-launch, funded startup that will be doing a couple local launches to get early traction and determine whether our business model holds.  We have some ideas on how we will launch this.  It looks like you've been through this exact thing before for a parallel kind of business so I'm hoping you can help me. 

Would you be open to a brief conversation around this?


I like to send these directly, but will do it indirectly through an intermediary when necessary.

Wednesday, November 14, 2012

CMO CTO COO Equity and Compensation

I was just asked about a particular startup situation (seed stage, CMO hire, non-founder) and particularly what compensation and equity is appropriate.  I know a lot more about CTOs specifically CTO Salary and Equity Trends 2009-2011, Visualization of Startup CTO Equity and Salary Data, Startup CTO Salary and Equity Data, but I've previously written about the issues with Equity for Early Employees in Early Stage Startups.

To find the equity numbers that were relevant for the particular person here, I went back through my prior post and looked at

Wilson Sonsini and DFJ Gotham Ventures


The Option Pool Shuffle


Employee Equity How Much

How much equity for investors and employees?

Seed Stage Compensation

What are typical compensation numbers?


Quick & Dirty How-To: Employee Stock Option Allocations

Monday, July 23, 2012

Lead Developer to CTO at a Startup

I received a great question via LinkedIn:

I'm the founding engineer and working hard to launch my startup.  I seem to encounter a lot of people who want to attach a CTO label to me as I'm the only programmer on the founding team of three.  While I do fill that role at the moment, I'm a little hesitant to refer to myself as a CTO as we still haven't launched a product, acquired a single user, or turned or a penny in profit.  I also recognize that while I am the first technologist on the team, I will not by any means be the last and I'm hoping that subsequent hires will be people I consider brighter and more talented than myself.  This leads to a set of questions: 

  • What is the role of a CTO in the early stages of a company, and does that role change later on as both the company and that individual matures? 
  • What can I do to best equip myself to step up when the need to officially fill this role arises? 
  • How will I know when the need has arisen? 

I've previously addressed the role of a CTO in early-stages in my post Startup CTO or Developer.  It specifically answers the first questions about role and how it changes as the company matures.  For example it includes the following kinds of things that a CTO should be addressing, but that may not be part of the expectation, time allocation, etc. for a Lead Developer:

  • How much will it cost to build what we need to build?  How can I control costs but effectively get stuff developed?
  • How can we phase development to balance cost, features, risk, etc?
  • What options do we have?  How do we balance those options?  What makes the most sense for us?
  • Given likely market changes, how will we design and build so that the systems can respond to marketplace changes?
  • How do we need to structure the systems to get ahead and stay ahead of the competition?
  • What are the biggest areas of technical risk?  How can we address this risk?
  • What technology research is required?
  • What technologies will we use?  What existing systems will we leverage, what programming languages, software development methodologies, web application frameworks, revision control systems, etc.?
  • What other kinds of systems will we likely need?  Accounting?  Reporting?
  • What are the important security considerations?  How do we balance concerns vs. cost?
  • Where are the likely future integration points with other systems?
  • What areas of the application are likely sources of scalability issues?  What kinds of spikes in traffic could we have?  How will we address these without significant cost?
  • How are we going to manage the product roadmap?  Make sure we make short-term progress, but not at the expense of longer-term objectives?
  • What do we build in-house or outsource?  What parts might we do off-shore, on-shore, in-house?  What does the staff need to look like over time?  When will key hires come on?
  • What other kinds of capabilities such as graphic design, user interaction, product manager, QA will we need?  Who will do that?  Who’s responsible for what portions?
  • How will we find and interview developers? 
  • How do we motivate and manage developers?
  • What do we need to do to make sure we can survive technical due diligence by investors and partners?
  • What specific technical innovations might make sense?
  • What can we build that might be protectable?
  • What metrics are going to be the key startup metrics and how do we get those metrics without too much cost?
  • Where and how will we host the systems?  What’s our purchase, licensing, SaaS strategy?
  • What other CTOs can I ask about complex questions to see how they’ve addressed these issues?

If you are a Lead Developer now and want to grow into a CTO role, there's some good news and bad news.  The good news is that many of the founders that I talk to who are trying to find the lead developer want someone who can grow into the CTO role.  The bad news is that there are a couple of things working against you making the transition.

Startups tend to focus on immediate development needs, getting product out the door, and are often short-sighted.  Then the Founder/CEO and the investors wonder why the above questions are not being addressed.  They attribute it to lack of knowledge and skills rather than focus.  Result => "We need to bring in a CTO."

Startups either grow or die.  If the startup lasts into a few rounds of investment, the rounds get larger, and the team grows.  A skills gap will emerge.  The lead developer who's used to leading a team of 3 will have a much different job trying to lead 40.  In fact, it's likely the case that it's better to keep the lead developer leading a small team to get product out the door.  It's also the sad fact that there's often a desire to bring someone in who has a bigger reputation and likely experience with larger startups that have gone through M&A or IPO.  Again, both of these will lead to => "We need to bring in a CTO."

There are definitely cases where the lead developer grows into a CTO.  However, I will say that there are MANY cases where the initial lead developer does not turn out to be the CTO of the series C/D startup.

What can you do to position yourself to make the transition?

Here's a dirty secret about most startups.  Unlike some larger, more mature organizations, most startups don't spend much time or effort helping grow their employees beyond the immediate needs of the startup.  Whatever the startup needs in the near-term is what the focus will be.  When they recruit you, they should tell you about what you will learn, but it will be focused on technologies and skills that they immediately need for the success of the business.

In the world of startups, it's critical that each person takes responsibility for managing their own career.

But that's most often not the case.  In How to Level Up in Your Career as a Startup Software Engineer, Pete Soderling points out something that's a bit of a dirty secret in the world of startups:

Many startup software engineers don’t take proactive steps to manage their careers.

Learning, Networking, Mentors

From the question, this person is clearly looking at the issue of how to grow into this role.  Likely one of the bigger challenges is simply not knowing what you don't know.  Towards this, I believe you need to seek out continuous learning opportunities.

If you are the senior most development leader, often there are organizations locally that you can get into where you can meet peers.  Here in Los Angeles, it's the LA CTO Forum - a private, invite only group of 250+.  The brain power of this group is amazing.  And it's quite common for people to get together outside of meetings to discuss issues they face and/or to seek a kind of mentoring relationship.  Finding an informal mentor or two would be a great way to be able to continue to focus on this and make sure you are caught unaware.

This group may be a bit unique, but in every geography there are lots of industry and technical organizations where you can seek out similar kinds of people.  You could even use LinkedIn.  I believe you will find lots of CTOs quite willing to help you as a mentor.

In addition to networking, I would suggest that formal learning is a great idea.  This can take the form of a local university, online courses, going through relevant books, etc.  The key here is to begin to avoid technology specific content and instead focus on management skills.  This is likely your bigger gap.

If you are seeking to ultimately be the CTO of a larger startup, it may make more sense to join an existing larger startup and learn from that CTO.  The size of the startup makes a huge difference in terms of the challenges the CTO faces. 

Make sure you are continuously looking at the business and customers.  Get in front of customers as often as you can.  Engage heavily on the business and product.

Allocate your time differently so that you focus on the issues that a CTO will be looking at:

  • strategy
  • communicating options and influence rest of leadership team
  • build/grow/direct/motivate team
  • financials/budgets

You'll note that a lot of the skills and focus of a CTO are around communication, business, management, team.  This is often a major factor in determining that transition.

I'd be curious what other advice people have.

Tuesday, June 26, 2012

Startups and a Common Misunderstanding in Agile Software Development

I've done four Free CTO Consulting Sessions in the past month with startup founders who all had run into variations of the same problem.  They didn't feel they had visibility into timelines and costs for development of their software.  They couldn't plan their business.  Investors and early customers were becoming worried about the ability of the founder to deliver.

In three of the cases, the founder was finding that the software teams (1 in-house, 2 outsourced) were delivering relatively well in the short-run.  The teams involved didn't seem to be exhibiting many of the Symptoms of a Weak Development Team.  The primary problem was that there always seemed to be a lot more that needed to be accomplished such that the big picture of what needed to get built was going very slow as compared to expectations.     As one founder put it:

We keep iterating over relatively the same features and functions.  We are finding and fixing bugs.  Making small changes.  But I'm now 4 months in on a release that was supposed to be done in 2 months.  And we are not even moving yet on the the next big release that I have to have to get my next round of funding.

In the fourth case, the founder was getting ready to sign a very large contract, but they didn't feel they had much visibility into what was going to be delivered.  Instead, what they had was a contract that promised Agile Software Development with Rapid Iterations and an incredibly vague list of features.  My belief is that you shouldn't sign that contract.  You are just setting yourself up for problems.  Actually, you are setting yourself up to be in the situation of the two founders that had outsourced.  They had both signed similar contracts and I'm not sure what's going to happen because clearly the outsourced developer is not delivering on the contract in terms of big picture features and functions.

In all four cases, I would claim that what's at fault is a common misunderstanding in Agile Software Development.  In particular, there's a tendency among many people executing an Agile process to focus on the short-term (Sprints, Iterations) and to forget planning and other big picture aspects.  There are many different Agile Software Development methodologies, but just about all of them have a strategic level element that focuses on the larger picture of the product.

Below are some pictures of Agile Development and you'll notice that each has a starting point of the big picture.





No matter what a developer implies or acts like, there is planning in their Agile methodology.

Of course, what's really at issue here is:

  • How much time/effort should be spent defining things that are farther away in terms of development?
  • How do we avoid continually iterating on a small set of product features/functions and lose progress on the bigger picture?

Level of Detail

So how deep do we need to go on features that are farther in the future?  Enough to have an estimate of the scope of the item.  I can hear the groans from all my fellow technical folks - we hate estimating things.  So why do I say this.  If you can't estimate it, then it's not defined well enough and you are just punting on getting it defined.  I'm not saying the estimate has to be exact, but a reasonable range is needed. 

I'm okay with splitting functions off into near-term and future.  A classic example might be "reporting" as a feature item.  What probably will happen is to define some early reports that will have more specific estimates.  Then as it gets into the distant future (12+ months out), it can be much fuzzier.

Why do I need this?  We are trying to establish the big picture over the next 6 months.  And we are using them to set expectations around what's going to happen in terms of the product.  If we don't force ourselves to the level of an estimate, we can't really do that and we'll have big time misunderstanding on what's going to get done.

For most early-stage startups the list of product features that are under consideration for a 6 month (or even a 12 month) period is not that big.   We are likely talking about an effort of 4 hours to 2 days.  In all four of the cases that sparked this post, the founder and the developer were willing to just put a single bullet item on a list (yes, "reporting" was a line item on one of them - ouch) that could have wildly different expectations and they clearly had not estimated these things.  In three of the cases, these were in contracts!  Of course, even for the internal development team, this is pretty much a contract with your founder.

You don't need a lot of documentation of these items.  I personally like the Product Backlog type approach, but with more functional description than user stories (that can be more open to misunderstanding by developers).  For example you might be capturing these first in user stories and then into a feature level spreadsheet that link back to the user stories.


You can also look at:

and there are tons of examples out there.  You will notice that all of them contain high-level estimates along with priorities.  This level of understanding only takes a few hours of time to get through.  Yes, it might be hard work, but you need to do this or you are setting yourself up for the kind of long-term misses that this post is about.

Unfortunately, there seems to be lots of confusion out there around this issue.  Part of this is confusion on terminology around various Agile methodologies and terminology.  But a big part of the problem is one of attitude.  A great post, Joe Little starts with acknowledging that Scrum and Agile proponents often downplay upfront planning.

... drowned out by Agilists saying "why do you want to do up-front planning?"

... all we 'scrumers' hate up-front planning

Joe points to reasons why proponents of Agile may try to avoid upfront planning including that things will change, so the initial dates/budgets are quickly wrong.  But Joe then goes on to point out why it's needed even with the negative attitude that Agile developers may bring:

  1. Help the business make decisions
  2. Team can see bigger picture and understand the tradeoffs
  3. Helps scope down early releases
  4. Team understands the whole project
  5. Leads towards Re-Planning

Also, take a look at:

The bottom line here is that neither the developer nor the founder/business owner should be willing to dodge upfront planning and getting to the estimate level.

Endless Iteration

The other problem that is being experienced is that each week the teams are setting the priorities to focus on bug fixes, small changes/new features around the same basic feature set and not getting to the next set of product backlog items. 

Okay, so part of this is a function of the quality of what is being built.  If there are a lot of bugs and each bug fix is causing new bugs, then it could be back to a Weak Development Team.  In these three cases, I would say that while I would have expected fewer bugs coming through the process with better development of test scripts, the overall symptoms were not horrible.  Most of the "bugs" were edge cases that were not really thought about until after the product was pulled together.  

The bigger part of this was that the business owners were defining additional features and functions that were needed now that they saw the system running.   In two cases many of these were coming from customers using early releases.  Some of these changes were important, but the critical question that I raised was:

What is the priority of these items vs. your product backlog items?

Many of the incremental changes and quite a few of the bug fixes were lower priority than moving on the product backlog. 

Why were they stuck in Endless Iteration?

  1. They had not accounted for the maintenance and support that comes with release.  If you start with an unrealistic picture of what's going to happen as you begin to release, you are going to create a big disconnect between your initial plan and what happens in practice.  As a developer, certainly as a CTO, you need to account for setting those expectations appropriately.
  2. They had not gone through a Re-Planning effort - mostly because they really didn't do any upfront planning.  If you look at Joe Little's last point about the value of upfront planning, it's setting you up for Re-Planning.  In these cases, not only did they have an unrealistic picture of what was going to happen once the software was released, but they continued with their pattern of not planning.  So instead of asking the priority of small changes vs. product backlog, they just sat in an endless iteration / maintenance mode.

I would also say that by starting into a process where you don't do big picture planning as you should, it shouldn't be a surprise when you are not making progress against the big picture.  You've established that the big picture is not as important as small increments and the team will align with that model.

Tuesday, May 22, 2012

Los Angeles Startup Events

I recently posted about the Increase in Early-Stage Startup Activity in Los Angeles.  In that post, I mentioned how one of the signals is the big increase in number of startup events and the number of attendees at those events.  I realized that it has been a little while since I posted about the Los Angeles Startup Community and so needed to update my list of startup events that will be out of date almost before I finish publishing it.

SoCal Startup Event Calendars

The following three sources are great at finding a lot of the startup events going on in Los Angeles and SoCal:
Even with all of those, they still often don't have all of the different meetings, especially smaller events listed.  So, you may also want to go look at:

Los Angeles Startup Events

Here are some of the events and meetups that I've spoken at, attended or at least interest me.  Of course, given the size of this list and having kids, I really can't attend a lot of these.  So, if you happen to read this and want to meet me, just reach out directly.

Monday, May 21, 2012

Startup CTO Speaking

Over the past several years, I've done lots of presentations around a wide variety of topics.  I was recently asked by an organization, "Tony, what topics can you cover?"  I realized that I've never captured topics that I've covered (I'm always willing to look at other topics), nor have I put up my speaker bio.  So, here goes:

Dr. Tony Karrer

Karrer-Tony-large-portraitOver the past 15 years, Tony has been a part-time CTO for more than 30 startups.  Most notably, he was the original CTO for eHarmony for its first four years making him partly responsible for more than 4% of the marriages every year.  He's also led  significant technology projects for a very impressive list of companies including Citibank, Lexus, Microsoft, Nissan, Universal, IBM, HP, Sun, and the list goes on. 
Tony has a Ph.D. in Computer Science and taught computer science for 11 years.  He is a frequent speaker at trade and industry events.

Select Startup CTO Speaking Topics

Making Sure You Are Ready to Begin Building Your MVP

So you think you're ready to start building your Minimum Viable Product (MVP)? Many non-technical founders miss documenting key features when communicating with their development team. In this presentation, Tony Karrer, a well known CTO for early-stage startups including eHarmony, will take you through the keys points you should consider before building your MVP such as: Features often overlooked when documenting an MVP for developers; Considerations when implementing social features; Understanding important metrics you want to measure; Risks and challenges in developing an MVP.

Building Your MVP as a Non-Technical Founder

Are you a founder who’s got a great concept and needs to get the product built? In this class, Tony Karrer, a well known CTO for early-stage startups including eHarmony, will take you through the keys to successfully getting your mobile/web product built.

Technical Advisors: Why Every Startup Needs Two, How to Find and Work with Them

After talking with several hundred startups over the past few years, there is a clear need for technical advisors to help specify the right things to build, make sure development is done right, plan past the initial MVP, review what is being built and generally cover gaps in the technical strategy and tactics.  Tony takes startups through the why and how of technical advisors.  Don't do a startup without them.

Ten Lessons from Working on 30+ Startups Over the Past 15 Years

Tony looks back over his experience working with startups and extracts elements that have led to success or failure.  Many of the factors are not obvious and include building mystery to drive margin, why boring B2B companies often win but are challenging in other ways, how bootstrapping wins, integrating metrics from the start and many other similar lessons.

Startup Feedback Panelist

Tony has participated on many panels where he can provide real-time feedback to startup founders.   Startups provide introductions and Tony and fellow panelists provide feedback in real-time.  These are exciting and fun experiences for everyone involved.

Evolving Role of Social Networks for Startups

In this talk, Tony traces the evolution of how startups have leveraged social networks and social media as part of their solutions over the past ten years.  Tony provides specific models and suggestions for how startups can leverage social networks for viral growth yet maintain their independence so as not to limit themselves long-term.

Matching for Startups

Having been involved in eHarmony from the start, Tony has naturally consulted with startups who are making matching a core aspect of their product including matching for social networks, careers, clothes, jobs, projects, college, tutoring services, doctors, service companies, investments, and many more.  As the web has led to exposure of every increasing numbers, people need ways to filter the possible options.   In this talk, Tony looks at where and how matching algorithms can be applied to give significant value to startups.

How Startups are Winning by Wiring into 3rd Party Services and Data

Probably the biggest change over the past 15 years in working with startups is the availability of 3rd party services that can be leveraged as part of a solution.  Its common for startups to think about services like hosting/computing, storage, analytics, maps, email delivery and tracking, and eCommerce.  However, there's really been an explosion of services over the past few years that gives even greater leverage and opportunity.  Possibly even more interesting is the rapidly growing data sources. In this talk, Tony first looks at the landscape of 3rd party services and data.  Then, he explores how several startups have leveraged those services and data in interesting ways.  He ends by looking at how this might help startups in the room.

Why Software Development Goes Bad So Often and What You Can Do About It

Most likely you've heard the staggering statistics on failure of software projects with different reports showing 28% success rates.  Tony is often called in after projects have reached a critical situation to try to help fix the problems such as blown budgets/schedules, poor quality code, never quite getting the last 10% done and other symptoms.  Unfortunately, for startups, the situation is often dire.  Development dollars have been spent and the system is not going to be able to be used for the business.
As a Startup, you have one shot.  What are you going to do to reduce your chance of problems and maximize your chances of real success?  What is the root cause of all of these problems?  How do you know if you may have issues?  What parts Agile addresses and the big problems with Agile for early-stage startups?
This presentation may make the difference between success and failure in your startup.

Metrics-Driven Startups

Virtually every startup has a model that has critical aspects to it that will make or break the business.  What is our lifetime customer value and how can we drive that up?  What does it cost to acquire a new customer?  What is our viral spread coefficient? 
The key for most early-stage startups is to understand the core metrics for your business, ensure you have visibility into those metrics, and then optimize the business around those metrics.  In this talk, Tony talks about the importance of these metrics for you and your possible investors, how startups typically gather these metrics without spending a fortune on reporting, and provides examples from eHarmony and other startups that may surprise you.

Stupid Things Founder Say - How to Work More Effectively with Techies

Software developers and other technical people are part of a very interesting club that has its own language, very specific rules, secret handshakes and, yes, they definitely talk behind your back and laugh at things that you say.  Unfortunately, once you've lost the respect of your technical team, it makes it hard to get work done and frankly becomes frustrating.  If you are not part of the club and don't speak the language, how can you work effectively with them?
Tony has been bridging that gap for 15 years with companies of all shapes and sizes.  In this talk, he helps you understand what you might be doing wrong today and how to change things to work with techies more effectively by understanding their motivation and getting yourself smart enough on critical items.

Monday, May 14, 2012

Startup Surge in Los Angeles

Ben Kuo just posted on SoCalTech:

Are the good times for startups back?

That seemed to be the mood running through the cloud at the more-than-sellout crowd at the Fairmont Miramar in Santa Monica Thursday at the first LA Demo Day. At the event, the enthusiasm for startups was palpable. The crowd of more than 1,500 spilled out into hallways, and would-be investors were turned away from the doors, as a crush of entrepreneurs, investors, service providers, wanna-be entrepreneurs, and others looked to be part of the surge of startups emerging in Los Angeles.

Certainly it feels like there's been a recent surge in Startup activity here in Los Angeles and as well nationally.  My two big data points are:

  1. What's happening in the Los Angeles Startup Events such as popular events like LA Demo Day.
  2. Increase in the number of inquiries I've been getting for: Free Startup CTO Consulting Sessions and/or other similar kinds of inquiries.

It has gone from 2 or 3 a week about a year ago to more than 5 per week. 

A lot of this action is early-stage startups and it's not clear to me how all of this will shake out given how hard it is for VCs to raise capital right now.

Are others seeing this as well?

Wednesday, April 18, 2012

CTO Salary and Equity Trends 2009-2011

Todd Gitlin of Safire Partners - a go to resource here in LA for recruiting C-level positions at startups - was nice enough to compile some data again this year (see last year's Startup CTO Salary and Equity Data and Equity for Early Employees in Early Stage ). Even better, my good friend and data visualization guru Steve Wexler of Data Revelations was able to create visualizations of the data.

Here's a live version of the data and below it is a bit of analysis of the trends.

I'm showing snapshots below. I would be very curious to get reactions to what people find in the live data.

CTO Salary and Equity Comparison

My guess is that most people who come here are going to be Founders, CEOs and CTOs who want to compare salary and equity of the CTO Position in their organization vs. their peers. Or they are looking at Hiring a CTO and want to see what salary and equity ranges look like.
Well the easiest visualization to use is to go to the Benchmarks Tab.
You then make selections around aspects like Founder Status, Job Title, Headcount, Revenue, Development Stage, Capital Raised, Funding Round, etc. If you get too specific, then the counts will get very small and may not be the best comparison. You can also enter salary and equity data to see where you stand.
As was pointed out in last year's post, generally there's as companies get older, have more funding, revenue, headcount, maturity:
  • Salaries go up
  • Equity percentage goes down

Trend #1 - Sizable Salary Increases

I've been talking for a while about the increasing demand for CTOs the past few years and a similar challenge in finding developers in Los Angeles. What I had not realized is that this had translated into escalating salaries for CTOs and VP Engineering. I was expecting that over the past few years, the pressure on VCs maybe had translated into lower salaries. It has not.

I tried slicing this a few different ways, but in virtually every case the trend is clear. CTO salaries are escalating quickly.

Trend #2 - Early Stage Companies Lower Salary and Higher Equity (for Founder CTOs)

The one exception to Trend #1 seems to be for Startup CTOs at earlier stage companies. If you look at the year-over-year trends from 2009-2011 for companies that have raised less than $10M:

and another chart that is only startups with Seed or Series A according to development stage:

To me this is a very interesting set of trends that I would not have guessed without seeing the data.
Anyone else a little surprised? Or seeing something else that's interesting?

Monday, April 2, 2012

Hiring Developers Before Product/Market Fit?

Using my StartupRoar as a radar, I came across a great post by Gabriel Weinberg Do you really need a full-time hire for that?

Hiring seems to be the preferred use of seed funds (by investors and founders), whereas I'd prefer a focus on customer acquisition.


The problem is you don't yet have product/market fit, and until you do, you don't really know what to build. And that should be the focus of the founders -- to find the special fit that will make your company take off. When product vision is truly clear, then it makes sense to execute it, and hiring follows.

In the mean time, if you need some extra help, get some contractors to test out specific things. You may end up hiring these people eventually and you'll know more about them when you do.

I'm not sure I'd carry the argument quite as far as Gabriel does, but I completely agree with his central premise.  When I talk with early-stage companies, often the discussion starts with them asking me about Hiring a CTO for Your Startup, or  Finding a Technical Cofounder for Your Startup or How to Find Programmers for Your Startup.  In other words, they come in asking for help with sourcing and hiring.  These companies are very early-stage and definitely have not shown product/market fit.  Far from it.

In many cases, during my Free Startup CTO Consulting Session with them, we discuss where they are in in the process.  They are very early.  They need to determine product/market fit.  They need to conserve cash.


The startup founder is definitely not ready to hire a CTO.  And in most cases they are not ready to hire developers either.

Instead, what they should be considering is how to bridge the  Startup Founder Developer Gap and exactly what they need in terms of Startup CTO or Developer.

They most often really just need either a Part-Time CTO or Technology Advisor, and then some combination of hiring and/or outsourcing (on-shore or off-shore).  The Part-Time CTO or Technology Advisor will be able to help make that determination.

Of course, there's still hard work to be done to as the bad news is that its hard finding good Web Development in Los Angeles and certainly its tough  Finding Developers Here in Los Angeles

Great post Gabriel!

Monday, March 12, 2012

Finding a Technical Cofounder for Your Startup

I've recently received several emails from people looking for a technical cofounder for their startup.  I promised I would write this post with some thoughts and ideas on the topic.  Here's an example of that kind of email.

"I'm looking for a partner / cofounder who can not only head the technical aspects and build a working model of the site, but someone with the connections to put a great development team together when we need it. "

Typically, this requires quite a bit more information for me to be able to respond and provide real help.  I've talked about that in lots of other posts, so you can visit some of these to help determine what you specifically need:

Key ingredients in the equation are:

Okay, so now you have it narrowed down and have determined that you need:

  1. Part-Time CTO or Technology Advisor to help guide you and close a bit of the Startup Founder Developer Gap, and
  2. Equity-Only Cofounder Developer - the first real developer that will work for equity and produce the bulk of the application.

Of course, you will want to figure out a bit more about the specifics of what this developer needs to know vs. can learn.  Your technical advisor can likely help.

Before you go out looking for your Cofounder, you should also be thinking about what will motivate them as I talk about in How to Hunt Programmers for Your Startup - A Field Guide.

The bad news is that Finding Developers is Tough Here in Los Angeles and even people willing to pay have a hard time finding Web Development in Los Angeles.   Of course, you are looking for something a little different - a technical Cofounder.  The bad news is that they can get a good paying job anytime.  The good news is that likely is not what they want.

Where to Search for the Technical Cofounder

So where might you run into the right person?  Here are some ideas:

In your company or other companies.  Find the developers in your current company and other companies that you can get inside.  Get to know the developers.  Find out who is good.  Ask your friends to do the same.  Take lots of them out for free coffee, food, beer.  Ask them about your concept.

Tech Events / Meetups - In Los Angeles, There are lots of Networking Events in Los Angeles and Southern California that are techie oriented.   You should definitely hit up the Startup Weekend events as well.  And look at for lots of startup oriented events.

Make sure you meet the people who run these events.  They often can help a lot in navigating to expertise and to possible resources.

Student Groups - Go to the local university and find out what student groups there are for programmers.  Ask around for ideas on where they hang out.

LinkedIn - This remains one of my primary tools.  It's a bit hard to use to find a cofounder, but I would certainly go ask everyone I know to introduce me to programmers they know.  And then use them to get to even more.  

Twitter - You can run searches for various types of techie terms being used in a given geography.  Follow them and reply to introduce yourself.

Befriend Recruiters - Most recruiters will not be happy I say this as they generally don't like talking to people in this situation, but they still often will have lots of ideas for where technical people in your geography hang out. 

Sites - There are a bunch of sites out there aimed at this or similar issues.  Most of them suffer from lack of activity, but it's worth a shot.  Some sites to check out:

You can try finding folks via

Oh, and often there are forums for particular technologies where you can look.

Here are a few perspectives on the topic of finding technical cofounders:

In Building a sweat equity team, Joel on Software tells us:

You simply need to network. Go to user groups. Go to tech (or other relevant industry) events. Refine your elevator pitch. Eventually you'll catch the ear, the vision, of someone who would like to jump on board, and has something you need in return.

A great post by Elizabeth Knopf , FounderDating: How I Found My Co-Founder where she breaks down the process much like how you think about a sales process.  I'm focusing on the sourcing ("lead gen" on her slide) aspect.


In Please, please, please stop asking how to find a technical co-founder, Jason Freedman tackles this a different way and suggests how you "earn a technical cofounder" along the lines of:

  • Learn to Code
  • Build the Front-End
  • Test on Paper
  • Build a Following
  • Spend Some Money

Here are a bunch of other articles on the topic of Cofounders.

  • How Much Equity a Technical Cofounder Should Get
  • 6 Ways to Find A Technical Co-Founder
  • Places to Find Developers in Exchange for Sweat Equity
  • How To Find A Programmer To Build Your Startup Idea
  • Bootstrapping a Lean Startup
  • Finding a Technical Partner for Your Startup
  • Finding Your Co-Founders
  • CTO Equity - Negotiation After Funding
  • Startup CTO Salary and Equity Data
  • Hiring a CTO for Your Startup
  • How to Hunt Programmers for Your Startup - A Field Guide
  • How I Found a Great CTO
  • We have a CTO, and so can you!
  • Why Your Startup Can’t Afford To Hire a CTO
  • Advice for CTO Founders: Don't Let Business Kill the Business
  • The Different CTO Roles
  • Why Your Startup Can’t Afford To NOT Hire a CTO
  • HOW TO: Hire the Perfect CTO
  • Finding a technical co-founder: You’re doing it wrong
  • How to find a technical Cofounder
  • Technical Cofounders are Overrated
  • A Minimum Viable Team is more important than a Minimum Viable Product
  • 7 Startup Co-Founders That Can Lead to Conflict
  • What is the best way to divide up ownership in a startup?
  • Ten Steps in Choosing the Right Startup Partner
  • Lockboxer CEO: You Don’t Need A Technical Co-Founder To Start A Web Business
  • How to pick a co-founder
  • The Co-Founder Mythology
  • Finding Your Co-Founders
  • Spencer Fry — Picking Your Co-Founders
  • Do I Need a Co-Founder: The 90/50 Rule of Startup Founders
  • How To Work Better with Your Co-Founder
  • How Do I Know You Are Mr. Right (Co-Founder)?
  • Why you can('t) recruit a technical cofounder
  • AskBob: Where do I find developer cofounder?
  • Things to Avoid When Recruiting Co-founders
  • Finding Technical Cofounders Is Hard
  • Need a Technical Co-founder? Hire a Product Design Lead First
  • Nailing that elusive technical co-founder
  • Thursday, January 5, 2012

    StartupRoar Adds Personalized Subscriptions

    Aggregage, the platform that powers StartupRoar has added a powerful personalization engine.  That means that the site now allows users to sign-up and have their content personalized based on their interests.

    You can sign-up via the "Personalize Your Content" button on the right side of the interface shown to the right of the red arrow below. 


    By the way, I should point out that the four top articles on the site when I took the screen shot were all great:

    It's what I love about the site.  It always has great, fresh content from a wide variety of industry professionals.  Every time I visit it, I find something that I missed that was really good content.

    Now with personalization it's even better. The picture below gives a sense of what's happening:


    Curators handle finding the best sources of content.  The system then uses social signals such as those coming from Facebook, twitter, LinkedIn, delicious as well as clicks and views.  These are compared to averages for the source and also looks at who is providing the signal, how often they signal things, how often they signal for that particular source, etc.  Those aspects existed before and it does a good job of finding great content. 

    What's new now is that the site allows you to sign up and provide your Twitter and LinkedIn information.   The site will look at your activity on these sites and the content of what you share.  It will use that to find interests as well as to cluster you with other users who are like you based on interests and sharing.  You can partially control your interests via the Subscription page as shown below:


    This will change over time based on your LinkedIn and twitter activity.  You can always visit and manually select interests as well.  You can read a bit more here: Personalization Explained.

    The system then can combine three pieces of information to figure out what will be most interesting to you:

    • Social signal score – are people in the audience finding it interesting
    • Topic match – does it match up with your interests
    • Like sharing – are individuals who are like you sharing this

    The system uses these to both rank things on the site and to generate Daily and Weekly newsletters.

    The reason that I'm most exited about this is that I partly use StartupRoar to make sure I don't miss things that is good content that is relevant to me.  Now with personalization, it is even less likely that something will sneak by. 

    I also personally like the format of the new newsletter.

    Give it a try and let me know what you think.