Tuesday, May 13, 2014

What Startup Advisors Do I Need?

Bob Dorf just published a post Where are the Hackers?  Solving the Founder-Tech Gap that came out of some fun conversations that Bob and I have been having.  A large part of this conversation is what kinds of advisors startups should be looking for.

A little while ago, I suggested that Every Web/Mobile Startup Should Have a Technical Advisor.  The conversation with Bob was about what the composition of advisors should look like.  We both felt that most startups are not taking a very systematic approach to defining with they need in terms of advisors.

Here’s the other aspect that both Tony and I preach: get help. You can’t afford and don’t want to hire a full-time CTO or architect. But, advisors, coaches, and mentors can often fill the bill. Getting someone who’s fully employed somewhere else to work with you on a limited basis to help close the gap is hugely important for the non-technical founder.

While Bob’s post focuses on Technology Advisors and the Startup Founder Developer Gap, we also discussed advisors more broadly.  I wanted to capture some of the broader conversation.

Formal vs. Informal Advisors

In many cases, you can get a couple coffee or beer meetings with advisors without ever formally engaging them as an advisor.  For me, if I can help you within a couple hours Free Startup CTO Consulting Sessions, I’m happy to do that and I don’t expect compensation or equity for that.  It’s not until it gets beyond the initial conversation or two that a formal relationship would be discussed.

There are a lot of people in the startup ecosystem that are happy to do this.  In creating Mentor Night, I’ve been happy to hear how giving most people are.  If you present a mentor with an interesting startup challenge in a space where they have experience or expertise, the mentors are quite willing to spend a few hours to help the founder.  And it’s way more fun when you have other interesting people in the room trying to also help.

Formal relationships make sense once you get beyond the informal stage, and it’s clear that there’s on-going need.  I recommend looking at the Founder’s Institute Founder Advisor Standard Template (FAST) Agreement as a template for this relationship.  Of course, you will want to work out the specifics of how you plan to work together with the advisor once it becomes more formal and adjust accordingly.

In some cases, Founders are building an Advisory Board with the purpose of padding their investor deck.  Investors discount this.  And it can hurt you if it’s purely cosmetic.  They may know some of your advisors and make a call after you meet with the investor.  

Connected Advisors?

I talk to many startup founders who select advisors in order to tap into their connections.  I’m not the biggest fan of this personally.  I side more with Mark Suster who says:

“advisory boards are an expensive equity proposition for merely introductions.”

Yes, you want connected individuals, but you often find that there are a few introductions that come easily and once those are exhausted, the value drops rather fast.

Domain Experts and Functional Advisors

Domain Experts have deep knowledge of your particular domain or aspect of the domain.  Maybe it’s knowledge of the players and dynamics of the mobile ad ecosystem. 

Functional Advisors come in with expertise in a particular area where you may need a second set of eyes.  This might be technology, marketing, sales, operations, international expansion, etc. 

Shafqat Islam looks at how he defined his Board of Advisors for NewsCred:

We spent a lot of time thinking about the exact roles and responsibilities for our advisory board. In that time I realized that we sought out very specific functions and had clear expectations.

Through this he defined aspects like “deep dives into our marketing strategy” and “product feedback and product strategy.”

This is a great way to go through and look at where you might have gaps and figure out what kinds of advisors you might want to approach for informal advice and then possibly formal advisory relationships.

In Bob’s post, he tells startup founders to get smart on product design, software architecture and development process.  That’s great advice.  But if the founder is just learning about these things, then those are gaps where getting advisors likely make sense.

Additional Thoughts on Advisors

Some additional random thoughts on Advisors and links to more information:

Monday, April 28, 2014

Working with Developers

There was a lot of passion in the room last week when I presented Working with Developers at the Stubbs Precellerator.  I guess it should not be a surprise that Founders have lots of challenges working with developers.  So I promised that I would provide a follow-up after the session.  This is that follow-up and hopefully it’s useful to people outside of the session as well.

Challenges

I started by asking the founders in the room to tell me some of the challenges they have working with developers.  Here are some of the issues that were mentioned:

  • I just want the cost, timeline and impact.  But my developers want to go into way too much detail.
  • I’m a long way into development and I’m 90% done and we are having issues getting it completed
  • Developers like to over engineer.  They often don’t take into account the actual business need.  In fact, they often don’t really understand the business.
  • Developers (and Founders) are challenged to know how much is okay in terms of bugs.
  • I’m challenged getting developers to work with me when I can’t pay them market wages.
  • Developers like to do things their way even when it doesn’t meet the needs of the business.
  • Developers don’t communicate well

We likely could have gone on from there, but I had thought this would be more fun, instead it seemed to be poking a sore spot and I could see the pitch forks coming out.

Let me come back to these at the end of this post.

Developer Motivators and Demotivators

Jim_Parsons_Comic_ConIf you’ve not watched the Big Bang Theory, then let me give you some homework.  Go watch a few episodes.  Being a geek myself, the writers of this show hit pretty close to home.  It may give non-technical founders a bit more insight into working styles when it comes to developers.  In particular, pay attention to Sheldon Cooper (pictured).  And keep in mind that developers consider you as weird as you may consider them:

“I'm sorry penny. But in this room you're the one who's peculiar.” – Sheldon Cooper

Developers want:

  • To solve something interesting, i.e., it’s an interesting technical problem
  • To have what they build get used and have impact
  • Learn from building it, ideally learning new skills and technologies
  • Praise for delivery, solving a technical issue
  • Have fun – but that’s often things like getting pizza delivered, time out for video games, celebrating a new release

Developers do not like:

  • Salespeople / Being Sold – talk to them without hyperbole.  Just to the facts. 
  • Time Wasters - Don't talk too much.  Stay on point.  Only go social when they go social. 
  • Pretending to know more than you know and not knowing enough.  Please do your homework so you at least know the basics.  But don’t pretend you know anything more than you do.  If you’ve ever seen an athlete use a big word in a slightly wrong way, that’s how you sound when you use technical language and you don’t quite know what it means.
  • Changing Your Mind.  If something changes in the business and it requires change, then you will need to cushion the developer as much as you can.  I’d first ask if you REALLY need to make the change.  It is hugely demotivating to be putting your heart-and-soul into one set of functionality only to have it change and basically throw away a bunch of work.
  • Estimating Cost – it takes a lot of work to do a reasonable estimate of cost.  The developer should be breaking out each individual piece of functionality and then coming up with a range of effort for the elements of that functionality.  It’s generally a good idea to go through each of these line items to try to better understand what’s involved, especially for the ones that are bigger or that don’t seem to line up with your understanding of complexity.  Do keep in mind that this is hard work for a developer.  And since they then get locked into whatever they come up with as an estimate, it’s also scary.  Have they considered everything?  If there’s some issue they didn’t think about are they going to be beat up about it? 
  • Re-estimating – if estimating is something they don’t like, then having to re-estimate costs based on a constantly changing target is brutal.  Don’t do this to a developer or they will hate you.
  • Setting the Deadline or using the works “Just,” “Easy,” or “Everyone does this.”  - It’s tough on a developer to explain why it takes work to get something to be built.  Adding pressure to this conversation makes it tougher.  It is better for them to come up with estimates on their own and have you go through to understand those estimates in a neutral way.  Do not ever say, “Here’s what we need and we need it by X date.”  You either need to be willing to take stuff out to get it down to something to hit the deadline, or you need to live with the date that arises from the estimate.  You also should never say something like, “We just need to add X.”  It implies that it’s something really easy to do.  “I just need you for a few hours to help me move this weekend.”  
  • Poor machine, screen, connection, chair.  If your developers have a better machine, screen, internet connection, or chair at home than they do in the office, then there’s a problem.  As compared to the cost of a developer, these are relatively inexpensive items.

Founder Developer Gap

image

The challenge for many non-technical founders is that they primarily need a lot of development to happen.  I.e., they need a developer more than they need a CTO.  What happens when you have a really good developer is that a gap exists where you may not ask the right questions to specify the right system, consider appropriate 3rd party technologies, etc.

This is something I’ve explored several times already in my blog:

Bottom line - for most startups, what they really need is a technical advisor or part-time CTO along with some development resources.

Other Topics Covered

I also covered topics that are covered more thoroughly in the following posts:

Some additional posts that may be of value:

As always, if you would like additional help please take a look at the following:

Challenges Revisited

Let’s look back at the challenges the Founders listed at the start of the session.

  • I just want the cost, timeline and impact.  But my developers want to go into way too much detail.

Developers rightly need a lot of detail to get at cost, timeline and impact.  Read Document Your MVP for a Developer for all of the detail that you really need to provide.  Of course, you probably are going to provide more of a feature list.  They should ask you for lots of details on those features and then give you some general estimates of size.  Maybe even something like small, medium, large, Xlarge. 

There is a balance here of how much granularity you want in your estimates and timeline vs. how much detail they want/need.  Have an open discussion with them about what you are trying to achieve through the questions.

  • I’m a long way into development and I’m 90% done and we are having issues getting it completed

See Symptoms of a Weak Development Team and Poor Software Developers - Pull the Plug Early.  This is a classic sign and you need to do something about it.  Ideally, you would have had a technical advisor, had better up-front definition, had more iteration, then you would not be in this situation.  Once you are here, it’s a tough spot.

  • Developers like to over engineer.  They often don’t take into account the actual business need.  In fact, they often don’t really understand the business.
  • Developers like to do things their way even when it doesn’t meet the needs of the business.

As a founder, you do need to be telling the developers what the business and product goals are.  Provide the metrics you are trying to achieve.  However, yes, there are a lot of developers who will take a myopic via of how to solve particular problems.  Many are not interested in 3rd party technologies that can streamline development. 

I just had a fellow CTO ask me about a particular technical design problem and several directions they could go and ask for my thoughts on the tradeoffs for those different choices.  For a younger technical person, this showed incredible maturity.  He was not afraid to show that he might not know the answer and ask for thoughts.  Plus he knew there were significant business trade-offs.

If your developers are not providing trade-offs to you around the range of choices that they see in their solutions, that means they lack real understanding of their role.  This is where a technical advisor can be hugely beneficial.  They can force a more open-ended conversation about what the possibilities are.  And what the trade-offs will be.

  • Developers (and Founders) are challenged to know how much is okay in terms of bugs.

Great question.  Generally I say that developers should be doing significant developer level testing, but in early-stage startups, testing falls back on the founders.  If too much is getting through developer level, i.e., they hand you stuff that’s obviously broken and tell you its “done” – that’s a bad sign.  But then it becomes your job to find every last edge case bug.  Collect them all into a single big list – I really mean an issue tracker.  Prioritize.  And then point the developers to them.   Good developers will see thorough testing as a blessing.  They don’t want to put out poor quality work.

  • I’m challenged getting developers to work with me when I can’t pay them market wages.

That’s correct.  The market is great for developers.  You need to inspire them with the product and market, and the learning opportunity.  Ideally you can pay them a livable number.  Take a look back at the motivators and demotivators.  It’s tough though.  You have to work really hard finding developers who are going to jump on board.

One other aspect is to make the development effort as small as possible.  The less you pay the faster your developers will leave.  If you have someone work for 3 months on something that will take 6 months to build, you will get very little from the effort.  The next developer will likely tell you they have to redo a lot of it.   Defining much shorter iterations on the way to a very small initial MVP.

  • Developers don’t communicate well

This one is going to take up it’s own blog post.  Communicating with Developers … coming soon.

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