Monday, September 30, 2013

Initial Conversation with a CTO or Technical Advisor

Are you a non-technical startup founder who’s about to go have a conversation with a Chief Technical Officer (CTO) or Technical advisory type person?   Maybe you are going for a reality check on your current situation - wondering if you have a Weak Development Team or a Startup Founder Developer Gap.  Maybe you are trying to determine what technologies might apply that you should be evaluating.  Maybe you have questions about the types of developers you need and even whether you need a Startup CTO or Developer or both.  Or you want to know about whether you have the right Web Development Company.  Or what else you might need in Document Your MVP for a Developer.

You definitely should be having these conversations in order to find out what things you might not be considering (Questions Developers Should Ask a Startup Founder) that are going to be important to your startup that as a non-technical founder you just don’t know to ask.  And this last one is why I tell every startup founder: Every Web/Mobile Startup Must Have a Technical Advisor.

Of course, when you go to have this conversation be prepared.  I recently had a phone call with an early stage entrepreneur that was incredibly frustrating.  I’d prefer that you don’t make the same mistakes.

Let me lay out at a high level the normal conversation you will have with a strategic technical person:

  • 1 min – small talk
  • 0.25 min (that’s 15 seconds) – why you are meeting
  • 10 minutes – overview of the business and key challenges
  • 30 minutes – questions and thoughts from the technical person

Let me run through these items.

The classic first mistake is to extend the small talk period.  If you’ve not already read How to Hunt Programmers for Your Startup - A Field Guide, go read what motivates and turns off a developer – CTOs and Technical Advisors are quite similar.  Small talk is not a motivator.  It’s not warming us up.  Don’t worry about going straight from “Hi, thanks for meeting with me” to “Well I want to respect your time, so let me dive in.”  Most technical people will appreciate you getting into things quickly.  Small talk is tough work for techies – so much so that people post to help techies with small talk.  Helping you with your challenges is fun.  Oh, and if you read that post, then you know that you will have earned bonus points by buying coffee, beer, whatever for the person as thanks for meeting/helping.  Yes, sadly, that still works on us techies.

image

The second item is important to make sure we are on the same page on why we are getting together.  “I have some immediate questions.  I’m hoping to get input on X, Y and Z, but I also want thoughts on what I might not know to ask about.  Depending on where the conversation goes, we may want to talk about how you might be involved in an on-going way.” 

The third item is REALLY important.  You need to be prepared to take the technical person through the standard stuff about the business that you would present up to an investor.  Actually, here are two posts with a pretty good list of background items you should plan to cover: Startup Software Development Homework and Free Startup CTO Consulting Sessions.  I personally like when founders have provided me this information prior to meeting for the first time.  It makes sure I know what the business really is, what’s the current state, and gives my analytic brain some time to process things.

A common, but really frustrating, situation is when a startup founder wants to hold back details about the business and product to protect themselves.  As a technical person, I’m sitting there trying to solve a problem.  But the founder is trying to hide the problem.  Argh!  I’m frustrated just thinking about it.  I personally believe the best answer is to provide what you would to an investor.  You don’t ask for an NDA from an investor before presenting.  Don’t ask it from a technical person.  If there’s some really secret sauce, let’s say a special Matching Algorithm, you maybe can hide some of the details of it.

Finally, we get to the fun part.  The technical person will begin to pelt you with questions about the business, product and technical challenges.

We are not trying to be annoying with our questions.  What’s happening is that we’ve translated what you said into initial thoughts around:

  • Business and technical risks  and mitigation strategies
  • Technical challenges and possible solutions
  • Possible third-party technologies that could be used
  • What needs to get researched, architected, built

You know how women complain that men just want to jump right to problem solving.  At the risk of offending lots of people …

 

Us techies are just trying to solve all of your problems as quickly as we can.  We love interesting challenges.  We want to narrow it down and try to solve it.  It would be great if you just have a big nail in your head.  Normally, it’s not clear.

Really, all the founder needs to do once we get into the back and forth is answer questions the best you can.  Sometimes you will need to give a technical person a couple of days to process things.  That’s another reason to maybe send background information ahead of meeting.

Okay, let me recap the mistakes:

  1. Not sending information ahead of time
  2. Extending small talk
  3. Not describing why you want to talk
  4. Trying to hide most of the business/product (i.e., the problem)

That’s about it.  And I feel much better now that I got it off my chest.  And I hope this will not dissuade startup founders from talking to me.  I REALLY do enjoy the problem solving.

Thursday, August 29, 2013

USC's Silicon Beach Awards and Presentations (Discount Code)

I was just down at Demo Day for the USC Incubator.  They had some pretty high quality companies presenting.  I just found out about a great award opportunity for people connected to USC (or who can figure out a connection in time).  I also have a discount code below for the event.

USC’s Marshall School of Business will host the second annual Silicon Beach Awards (SBAs), a $50,000 venture competition focused on innovation in technology & entertainment. The SBAs are a key part of the http://siliconbeachusc.com/ event which is co-sponsored by USC’s Marshall School of Business, School of Cinematic Arts, and Viterbi School of Engineering. Startups that consist of at least one USC student or alum (less than 10 years from graduation) are encouraged to enter – and have a chance of winning up to $25,000!

Silicon Beach Awards deadline is September 2!!

Apply here: http://bit.ly/1bqAGbf

ABOUT THE PRIZES

Significant cash prizes will be awarded to the top 3 teams: First place: $25,000, Second place: $15,000, Third place: $10,000. In addition, the top three finishers will also receive legal services from Edwards Wildman Palmer LLP, a premier law firm located in in the US, UK and Asia who are working with Fortune 500, FTSE 250 clients and start-up companies throughout a range of industries.

Presentations Silicon Beach @ USC – September 18, USC Campus

USC will be hosting its 2nd annual Silicon Beach event on September 18 on the USC campus. Silicon Beach @ USC will feature game-changers and thought leaders from Hollywood studios, technology startups, and academia.

Presenters for the September 18 conference include:

  • Albert Cheng, EVP & Chief Product Officer, Digital Media for Disney/ABC TV
  • Hamet Watt, Co-founder &Chairman of MoviePass
  • Ric Whitney, Head of VOD/EST for Intel Media
  • Karen North, Director, Annenberg Program on Online Communities
  • David Watson, Director of Product Innovation, Kids at Netflix
  • Jason Corsello, CMO, Cornerstone OnDemand
  • Dan Brian, EVP of Media at DemandMedia.
  • Ashish Soni, Founding Director, Viterbi Students Institute for Innovation(VSi2), Executive Director of Digital Innovation, and faculty member, USC Viterbi School of Engineering
  • Jimmy Liu, CEO, Gymflow
  • Rajiv Maheswaran, CEO,  SecondSpectrum
  • Jens Windau, CEO, AIO Robotics
  • Kevin Winston, founder, Digital LA

…and others!

We will also recognize the next generation of innovators as we award over $50,000 to participants in the USC Silicon Beach Awards venture competition. 

To join us, register at https://siliconbeachusc-2013.eventbrite.com/  Use the promo code FriendOfCTM for half-price admission through Sept 11!

More info on the conference and the venture competition at http://www.marshall.usc.edu/news/events/2013/silicon-beach-usc

To register at the discounted price use the promo code: FriendOfCTM

1. Go to https://siliconbeachusc-2013.eventbrite.com/

2. Click on the “Enter Promotional Code” link at the bottom of the “Ticket Information” window

3. Add this promotion code: FriendOfCTM and click APPLY

4. Choose the Industry Guest - Early Bird ticket. Your fee will be reduced to $75 as long as you register by Sept 11. (Afterwards admission goes to $150.)

5. Choose the number of tickets (up to 4) and complete the form.

Tuesday, May 21, 2013

Founder Challenges with Startup Development Teams and CTOs

I'm spending more of my time recently working with non-technical startup founders who are having challenges with their software/web/mobile development teams.  I thought it would be worth capturing some basic notes about what signals founders commonly are seeing that cause them to call me, what those signals might be indicating, and what might make sense to do as a founder if you are seeing some of these signals.

Common Signals

I've written previously about Symptoms of a Weak Development Team.  These are often the same things that cause a founder to reach out to me about helping their CTO, VP Engineering, tech team, off-shore development, etc.  Some of the top symptoms are:

  • Frequently missed deadlines. 
  • Everything takes a long time to build.
  • Delivery of code/product that clearly has not been tested.
  • Rogue developers with their own agenda.
  • Not sure what's being built when and by whom on the team.
  • Fixing one thing breaks something else.
  • Bugs – no big deal.  The system keeps crashing – no problem.
  • Annoyed at testers for finding bugs.
  • Same problems seem to occur all the time with no desire to look at what’s behind the problem.
  • All new features seem to require significant rewrites and a ton of development time.
  • One of your better developers leaves.
  • No questions being asked (32 Questions Developers May Have Forgot to Ask a Startup Founder)

And the #1 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%.

On the other side, signs that your team is doing well are:

  • a high service level and availability of the product/system
  • a high throughput of effective change
  • a low amount of unplanned work
  • a culture of change management
  • a culture of continual improvement
  • a culture of root-cause analysis

Source of the Problem

Most of the time, the cause of these challenges come down to:

Communication / Process

How well does the C-level team work together to define priorities, specific development tasks?  How strong is product management?  Is there a lot of rework?

Architecture

All startups will make a lot of changes and scale the product as they move along.  This means that early software architecture can sometimes not work as well as the startup moves forward.   Some amount of issues with this is normal.  On the other hand, sometimes architectures are very poorly done and causes significant problems every step of the way.

CTO Knowledge and Skill

I personally believe that the best CTOs will have a technical/developer background.  It's hard to manage a development team when you are not very technical.  Unfortunately, having a technical background and being a good coder doesn't necessarily translate well into being a good CTO.   Let's consider a brief description of what a CTO needs to be able to do.

Strategy, Planning, Key Relationships and R&D.  A CTO is responsible for understanding the needs of the business, the product direction short and long-term, establishing the overall technical direction, building and managing the development team, and leading all aspects of technology development in a way that ultimately leads to the best outcome for the business.  They need to take a critical role in the strategic direction helping the business navigate critical product/technology choices.  They often are involved in key client accounts, partnerships and external relationships.  Sometimes they will lead key product tests, special projects, essentially research and development.

Technical Direction.  Establishing technical direction can be really hard these days.  There are new things flying at you all the time.  It is extremely hard to be a adept at all of the technologies involved in a startup.  One of the real values of the LA CTO Forum that I run is you can quickly get input on different technologies. 

Technical Leader.  As leader of the technical team, they need to build the best team possible given the needs of the business.  They need to establish the development and support process and development culture.    This obviously extends beyond the development team and requires integration with (or ownership of) support and operations. 

Don't Wait

If you are seeing these signals, then you likely have at least one of the above sources of challenges.  A lot of founders will wait and hope that the technical leadership can sort it out.  That often doesn't happen.  These problems need to be addressed right now.

If you look at the sources, these are not things that just go away on their own.  Instead they tend to get worse: 

  • Once you lose trust with a CTO and the development team, it is hard to get the trust back.
  • If the CTO/team has made some bad technical choices early such as the wrong architecture, every dollar you spend will be partially wasted going forward.
  • Developers will leave.  They don't like this situation either.  This puts you in a tough spot.  Transitioning early on your terms is better than when you are under the gun.

Waiting will only make things worse.

Get Help

The reality is that as a non-technical founder, it is often very hard to get to the heart of the issue with your CTO or development team.  Walls quickly go up.  They snow you with technical aspects.  So what do you do?  Get help.

My bias is that the help you want is from a good CTO who can come in as a peer of the existing CTO.  They will be able to understand what is going on, make suggestions, coach and otherwise help.

Help can come from CTOs at other startups on a formal or informal basis, or CTO consultants (like me).  Often you can get a pretty good handle on sources of problems by having a CTO or consultant come in for a few hours to talk with a few people from the C-team and the technical lead.  This will quickly uncover communication and process issues.  Issues with the architecture and technical team will take longer to diagnose. 

Of course, turning around these issues will take some time.  Building skills and knowledge of the CTO takes some time.  Getting processes into place and operating effectively takes some time.   But it makes sense to start now as the problem will not fix itself.

Related Posts

Technical Advisors: Every Web/Mobile Startup Must Have One

Founder Developer Gap

Tuesday, April 9, 2013

Selecting a Web Development Company

I've written before about finding Web Development Firms in Los Angeles.  What I didn't discuss was how you should go about selecting the right company.  I just got an email asking about exactly this:

I'm with a new company that needs some software built, but doesn't need (or have the resources for) a large staff of software developers.  They've been in talks with some consulting companies, but don't quite the know the criteria for evaluating them and things like references(and where to get them).

So here are some thoughts on selecting the right firm.

What Do You Need

imageIt's critical to know what kind of skills you really need.  Different firms will have very different skill sets:

  • Do you need user interface design?  Graphic design?  Do you have the basics already defines and just need it to be fleshed out?  Or are you starting from scratch?
  • Do you have the functionality defined?
  • Do you have some complexity around algorithms, database?
  • Do you have scale issues now or later?
  • Are there particular technologies or platforms involved?

You will find firms that are design/interface heavy and light on development.  Others that are heavier on development.  Some will have some specific skill sets.  You may find that you want a combination of these skills and want to look at finding them in different people/firms.

Most of the rest of the post is going to focus more on finding development rather than design firms.  If you need user interface and/or graphic design, that's a slightly different selection process.  Some of what I have below applies.  And you will want to make sure you see what the particular designers have done, samples of their work product, their process, etc.  Make sure you know who will be doing the actual work.

Selection Criteria

Here is what I would be looking for:

  • What have they worked on?  Who worked on those projects?  Are they still at the firm?  Have they worked on projects that are similar to your project?  Have they used the technologies that are involved in your project?  And make sure you see those projects.

    Don't be swayed by big name firms or other kinds of name dropping.  I (and TechEmpower) have worked with IBM, HP, Xerox, etc.  That says something.  But it's quite different working for large firms than it is with startups.  Make sure you know exactly what the company did on each project.  And they should not get to count items in their portfolio that were done at another company/job - yes, that's quite common, especially in new firms.
  • Quality Result.  Make sure that what they produce looks and acts right.  See it in action.  Some developers just don't quite get that you need to produce a quality result.  That said, don't be fooled by things that look really cool when you need functional results.  You are looking for someone who cares about the look, but you are hiring the development firm for it's development skills not its graphic design skills.
  • Are they asking good questions?  You should be getting an estimate for the work effort before you get started.  Do not fall into the trap of Startups and a Common Misunderstanding in Agile Software Development.  To provide you an estimate, they will need to ask you a bunch of questions.  It's shocking to me that many firms will not ask questions.  They will give you a quote.  Run away.  They are either not seeing the questions that need to be asked or not interested in finding out what you really need so they can provide a reasonable estimate.

    By the way, there was somewhat a trick question above "Do you have the functionality defined?"  You may think you have it pretty well defined.  But show it to a decent set of developers and they should be able to make your head swim with all the things you've not considered. 
  • How good is the company's own site?  They shouldn't be showing you that they don't care at all about looks and content on their own site.  But if their site is really gorgeous, that means they are good at design, not necessarily development.   
  • How many full-time W2 employees do you have?  How many contractors?  Where are they located? (have you seen the offices?)  What are the skills of employees vs. contractors?
  • What's their process?  How do you know if you are on track with development?  How is testing handled?  What are the review periods?  What's my responsibility in the process?
  • Are budgets and deadlines hard or soft?  What percentage of their projects launch on-time and on-budget as compared to what they estimated up front?  How do they achieve that result?
  • How do you communicate?  Is there a project manager?  This can be both good and bad.  Some project managers get in the way of effective communication.  Have conversations with the point person and make sure you will be comfortable with them and that they will add value to the process.
  • What do they do after the web site is launched?  Do they help with transition to in-house or other developers?
  • What's the plan for hosting and support?
  • Do they have repeat or long-term clients?
  • References.  They should be willing to share references.  But you may also want to get in touch with people at companies that they have been showing you as part of the portfolio.  You can find and reach them through LinkedIn.

Problem Signals

All of the following are signals to me that there may be risks/issues:

  • Not asking questions.
  • Not asking you what your plans are for mobile.
  • Recommending Flash.
  • The firm is less than two years old.
  • The firm is smaller than 10 people.
  • The firm is completely virtual.
  • They didn't ask you some of the questions in: 32 Questions Developers Should Ask a Startup Founder.
  • They have the lowest price out of several vendors several of which come in at roughly the same higher price.
  • They believe there's no maintenance after launch.
  • They don't seem to care about you or your project.
  • You are feeling like you are being sold.

Tuesday, April 2, 2013

Making Sure You Are Ready to Begin Building Your MVP

I'm presenting Making Sure You Are Ready to Begin Building Your MVP next week at Coloft (Details/Registration).  I'm going to be looking at aspects like:

  • Things to consider before building your MVP
  • Features often overlooked when documenting an MVP for developers
  • Understanding important metrics you want to measure
  • Risks and challenges in developing an MVP.

It should be a fun evening with lots of interesting conversation.  This post will provide links to participants as well as to readers.

What's Going to Go Wrong

A lot of founders don't really understand Lean Startup principles.  They look at the following high level definition of Lean:

image

and they interpret that as write up an executive summary with your ideas and hand it to developers to build.  What's going to go wrong?  Well I often get the unfortunate call from startup founders where all kinds of things have gone wrong:

  • Built the Wrong Product
  • Poor Product Quality - Code is really bad, full of bugs, missing critical features
  • Doesn’t Scale Past a Couple Users
  • Not Protected – Access to Code, Rights on Code

MVP Homework

Why are you building your MVP in the first place?  See Investors, MVPs and Evidence of Traction

Have you conducted Problem, Solution and Feature Interviews with customers?

Have you Documented Your MVP for Your Developers?

Have you looked through Things You May Have Forgot in Your MVP and provided answers to these?

Do you have a Technical Advisors: Every Web/Mobile Startup Must Have One?

Don't be fooled by a Common Misunderstanding in Agile Software Development.

While You Are Building Your MVP

Look for the following Symptoms of a Weak Development Team.  Correct your course quickly.  And when you have Poor Software Developers - Pull the Plug Early.

Learn how to test and possibly use testing and load tools.  See: http://www.softwareqatest.com/qatweb1.html

Additional Resources

Thursday, March 28, 2013

Web Framework Performance - Startup Founders Need to See These Numbers

In Web Framework Benchmarks, there are some very interesting and surprising numbers around the performance of various web frameworks.   Startup Founders really need to see these numbers.  And I hope you are not running on Cake PHP when you see these numbers.

Many of us are putting more into the front-end and having the application logic and back-end exposed through JavaScript (JSON) APIs.  In some ways, this frees us from worrying as much about the specific framework that's being used.   I've found myself looking mostly at talent and time to market.  But these numbers are causing me to pause a bit and really think about the choice of framework in terms of performance.

In looking at these numbers, seeing Cake PHP at 500x slower, Ruby-Rails and Django at 50x slower really surprised me.

I was also surprised by the performance improvement on dedicated hardware as compared to EC2 instances of roughly 10x. 

Important Implications

Well I'm currently working with startup founders on their systems in JRuby, Django, PHP and Java. 

Several of these are B2B applications with relatively smaller audiences.  I'm feeling okay about our choices of frameworks that are slower and will cost more in terms of hosting and managing growth.  The availability of talent was an important factor.

However, startup founders who are building applications that have:

  • Large Audiences - consumer facing
  • Complex Processing - examples: Matching, Social Network Analysis, Compatibility Scoring, etc.
  • Database Intensive

need to consider going with a higher performance solution.  Most startups do not get a chance to move from one framework to another.   It takes a lot of time and effort and the result is that you get to go through a whole new set of bugs only to get back to where you started but with a faster, more scalable application.  Think about twitter - but they had lots of money.

Often we justify building an MVP in whatever framework is fastest to build or where we have resources that know that framework.   You may get into the market, but just know that you are going to pay the price when you start to get traction.

Monday, March 11, 2013

Investors, MVPs and Evidence of Traction

Yesterday, I was talking to a startup founder about their MVP and they said something that finally got me to write this post:

"I have a few investors interested but they want to see a product."

In Building Your MVP as a Non-Technical Startup Founder, I mentioned that before you build your Minimum Viable Product (MVP), you need to be really clear on your purpose. 

In most cases, when you are building your MVP, you are trying to prove out certain startup metrics such as:

  • Cost of Customer Acquisition
  • Conversion Rates / Pricing
  • Viral Coefficient

in order to get those numbers in front of investors so that you have evidence of traction and can show that you can begin to build out more of the real product and begin to scale the business.

It is almost never the case that you are building an MVP to "show" to an investor the product itself.  Yes, the investor may literally have said to you:

"That is something I'd seriously think about investing in when you have your product built."

But the reality is that they don't mean that.  Two aspects to this:

  • You can let an investor see your product via a mockup or clickable prototype.
  • If you do build the MVP and show it to them, they will ask you about your metrics.  They really want metrics, not a product.

A Mockup is Enough to Show the Product

Most investors can look at a mockup or clickable prototype and have a pretty good sense of the product.  They may wonder if it can be built technically, but I (or other CTOs) can answer that question without building any code. 

Cases Where a Mockup is Not Enough

There are a few cases where mockups or clickable prototypes may not be enough:

  • Usability, interaction design, etc.  For example, the iPod won not because of better features and functions.  It won because of interface, ease of use.  To get an investor excited about another MP3 player at the time, they would have needed to play with the interface.  That said, you likely could have still come up with some cheaper way than building the iPod.
  • Results of Algorithms.  Often you can't tell if something like a search engine or matching algorithm is really going to have better results until you use it.  You may have to build something out to show it working for someone to evaluate whether it really works better than what else exists.

I would guess that this represents less than 5% of startups.

Investors Really Want Evidence of Traction

So you built your MVP; you bring it to the investor; you demo it; and I will guarantee they will ask you:

"So how many users do you have? 

How much is it costing you to get users? 

How much are you making from your users?"

And other similar questions.  Yes, they are happy that you have your product built and that does make it much more investable.  But now that you have a product, you should be able to show that people want to and/or are willing to pay to use it.

Bad News?  Not Really

At first you may be thinking that this is all bad news.  Wow, now Tony is telling me that not only do I need to build my MVP, but I need to actually show evidence of traction.  That's an even tougher hurdle.  Yes, that's correct.  Sorry, but that's the reality.

However, the good news is that for most investors, you can certainly change the question and get a lot more information without ever building the MVP.  The real question you should be asking is "When I've built this product and show you the following metrics, would you invest?"  The "this product" will be a well formulated mock-up or clickable prototype.  If you don't have that, then you will naturally let the investor off the hook by saying, show me the product.

I actually think you can push the conversation pretty far with most investors and a few good mockups.  No, you won't know if you will really get a check - most investors are hard to actually get a check from - but you will have a pretty good indication. 

Bottom line is that before you go and build your MVP:

Additional Sources

How Much Traction is Enough for Investors?

But never forget that traction is necessary, but may not be sufficient, to lower the risk perception of investors, and assure an investment. The quality of the team, and overall financial health are equally important, as well as how your offering compares to competitors.

Now that You've Got MVP, It's Time to Think About MVC

You can't raise money on achieving an MVP. Investors demand more than that.

As Steve Blank likes to say:

A Startup Is a Temporary Organization Designed to Search
for A Repeatable and Scalable Business Model

The unfortunate reality is - an MVP is not the above! Yet most of the newly minted entrepreneurs I've met think their job is nearly done when they've found MVP - they think they can go build a pitch off their early MVP and raise money!

A startup does require MVP but it is much more than just MVP. The problem is that MVP means early adoption of product and its features, maybe even some who will pay. But it doesn't tell you how many people will do it in the long term and whether this can support the company (the people and operations within) that is behind it.

What The Heck Does “Traction” Really Mean To A VC?

Great analysis from John Greathouse:

investor-evidence

investor-evidence-2

Do You Speak VC? A Beginner's Guide to Investors

How to Speak the Language of Venture Capital