Monday, December 14, 2009

Startup Software Developers

Just saw a great post by Mark Geller - Developers wanted… in Los Angeles, U.S.A.  (you can get to know Mark a bit more in my post Product Manager Entrepreneur Mark Geller).  Mark tells us:

there is a lot of demand for developers right here in L.A. If you have solid web skills and a few years experience, either with a commercial company or running your own legit projects, there are dozens of companies in L.A. who would love to talk with you.

There’s quite a bit of truth to what Mark is saying about startup software developers, but my guess is that there’s another reason that it seems harder to find developers in this context.

First, early in the post, Mark mentions:

The idea behind the meetup is to connect technology startups with prospective hires who may be interested to work for “alternative compensation”–e.g., reduced salary, partial equity, good experience, etc.

So, likely quite a few of the people who were seeking startup developers were looking to find people for very low dollars.  “I’ll give you equity in the company.”

Second, there’s this funny perception that the cost of software development have been dramatically changed in the past few years.  They haven’t.  While the cost of hardware, hosting and networks rapidly falls, software gets easier to build at a much slower rate.  If you have some complexity and uniqueness to your startup (and you should – see Matching Algorithm), then it’s going to still take time and effort to do the software development.  Likely a lot of time and effort.

Again, though the perception is that it won’t take that much work – oh and I’m going to pay you little or nothing to do all that work. 

My guess is that this compounds the effect.

That said, it definitely is difficult to find really good startup software developers.

Wednesday, December 9, 2009

Startup Software Development – Do Your Homework Before You Develop Anything

I just had an all-too common conversation with the founder of a startup who had spent more than a year working with a software development company who had produced a mess. The mess really comes from a developer who was willing to get started on a product that was not fully thought out.

I always take a very different approach in early conversations. If I’m being asked to do startup software development, I’m going to push fairly hard on key questions that the startup needs to have answered before they develop anything. Some founders are taken aback. They are calling me to go build what they tell me to build. Why would I question whether they’ve done their homework? And most often I only know enough about their business to be dangerous. So why ask all these questions if I might lose a potential client?

If I don’t ask the questions and do a little bit of homework, then likely we will end up with a mess.

So what are the questions I’m likely going to ask?

  1. Tell me a bit about yourself and why you are doing this.
  2. Who are the customers? What’s their specific need / pain? Please be able to provide me with a few specific examples of different types of customers, what they need, what the system will do for them.
  3. Tell me about the business. How are you funding this? What level of funding do you currently have? What are the big milestones you have as a business? Do you have any specific deals done that are a basis of this?
  4. What’s different, special here? Where’s the mystery (see Matching Algorithm)?
  5. Who are the other stakeholders involved? Other types of users? Partners? Administrators?
  6. How will you be taking this to market? What channels will you use (e.g., SEO for Startups)?
  7. What are your key Startup Metrics? How do you make your money?
  8. What already exists in your space? Who are your big competitors? What are some good examples of similar sites?
  9. What special data, content, APIs, etc. are you going to leverage? What’s the state of the relationships that brings you that data? What’s the state of those systems?
  10. Where do you stand on your brand, name, logo, positioning? Examples of other brands/sites that are similar from a brand perspective?
  11. Are there any specific hard dates or important time sensitive opportunities?
  12. What do you see as some of the bigger risks / challenges?

Of course, we’ll also discuss the details of the product itself. What does the system do? How does it address the customer scenarios from the start? What's the User Interface Beyond the Web Site? What specific business logic is implied? Etc. This discussion always is at a pretty high level in initial conversations and then drills down from there.

Yes, a lot of these questions are partially answered in a business plan / presentation deck / marketing plan. That’s a great starting point for the discussion, but it’s never been complete in terms of answering all of the above questions.

A lot of the product discussion feeds off the answers to this conversation. We’ll spend quite a bit of time discussing specifics of early versions of the product that will achieve specific business milestones, or reduce certain risks, or prove market, or whatever it is. Without the context of the above, it’s hard to make good decisions from a product and technical standpoint.

In a fairly high percentage of cases, by the end of the conversation (in an hour or less) we are discussing a slightly different system than what we discussed at the start. If you are finding that your system definition is changing as the result of this conversation, then it means that more homework is needed. Actually that’s it…

For startup software development, before you build anything, make sure that doing more homework, asking more questions, doesn’t result in substantially different definitions.

Iterate until you have a stable definition. Then move fast towards a small first phase. Sounds simple, but there’s a lot of work to be done. Of course, that’s the really fun, interesting, challenging work.

Monday, December 7, 2009

User Interface Beyond the Web Site

I talk to a lot of founders of startups.  My initial conversations normally focus on the core of the business, important Startup Metrics, probably marketing strategy (ex. SEO for Startups and Negative Customer Acquisition Costs) and, of course, the product itself.  Normally the product is defined as a web site.  Most founders are fairly passionate about the features and functions of the web site, iPhone application, Facebook application, or whatever web application represents the product.  And in many cases, they come with a fairly robust description of what the user interface for the product.

But one of the really interesting things in these conversations is that founders often forget what I consider to be “the other user interface.”  What do I mean by the other interface?

Well think about where you spend your time on your various computing devices?  What applications and web sites have you been using?  For me, my number one application is email.  Then I spend time in all sorts of other applications and web sites.  But the number of web sites and applications that I go visit directly and use is pretty small.  And it’s fairly rare that I add to that list.

For most web products, the way that I end up going to them is that they somehow remind me that they are out there and have something of value.  How does that happen? Well likely it’s email.  It might also be through twitter, Facebook, SMS, RSS, voice, etc.  And the common thread is that all of these provide a means for a product to message the user without them having to think to go to the site.

Don’t be a Ning!

A pet peeve of mine is the way that Ning handles updates to discussions.  They send me a notification that there has been an update to the discussion thread.  It does NOT contain the contents of that update.  To see the contents you have to click a link to go to the site.  I believe they are doing that solely to get me to go back and visit the site so that maybe I’ll click on an ad.  Yuck!

Ning could easily send the contents of the message.  And they could even allow me to send an email response so that I would never have to go to the site.  They could also do this through SMS, Twitter, etc. if that was my chosen messaging platform.

In fact, if Ning cared about making a really powerful tool for distribution discussion, it would allow the discussion to range across all of the channels with each user controlling the flow of the messages.  But none of the users would be required to visit the site.  If you get an SMS, it’s often not practical to visit a site.  But a simple SMS response is quite practical.

Ning clearly is not trying to optimize for effective discussion.  Instead, they are trying to optimize for page views (and ad views) and creating a rather limited tool for discussion.

Bottom line - Don’t be a Ning!

Instead Extend Your User Interface Beyond the Web Site

As was described above, an alternative to a web site for discussion is a distributed interface available through various messaging applications that support distributed discussion.  I’m not claiming this is always appropriate, but the point is that you need to think about this other user interface that’s a critical part of the overall user experience.  In other words …

The user interface beyond the web site is the one that allows the user to interact with your product through their existing sites, devices, applications -- primarily messaging sites, devices and applications -- so that they can continue to use your product even if they are not visiting your product.

Questions to Spark Design Discussions

Some interesting questions to ask about the user interface beyond the web site:

  • What parts of your product can be effectively accomplished in the other user interface?
  • What other user interface opportunities do we have?  What sites, devices, applications are our users going to be already using?
  • How will the other user interface possibly help us with acquisition, retention and referral?

By asking these questions, almost invariably we begin to see the product design in a bit different way…. 

Many applications can push quite a bit of their functionality into these messaging layers.  If you think about email, especially HTML email with the ability of users to respond via links … a lot of the application can get put into the email.  Possibly this creates a much better user experience because the user doesn’t have to think to go to the site or leave their current context.

Limited Budgets

Of course, I’ve yet to meet a startup that had enough money and time.  Thus, you still need to make lots of choices about the functionality to arrive at effective minimums.  So, while I’m pushing a particular discussion, the reality is that often the other user interface turns back into emails.  That’s just fine.

The real point here is not that we should necessarily push for all sorts of messaging out of the gate.  Instead, it’s to think of messaging as a core part of the user experience and even as part of the user interface.

Bottom line: the user interface doesn’t stop with the web site.