A History of Product Development at betaworks

I recently (December 8th) gave a talk at the betaday 2010 - a small private conference put on by my company, betaworks - covering the history of product development there. I was excited to present because of the occasion, but also since I got to talk about product development.

John Borthwick has a simple framework he uses to describe our approach to creating products, and it goes something like this: Inception, Iteration, Scale. The overall approach is similar to Paul Graham's Six Principles for Making New Things and lean startup techniques like Minimum Viable Product. A key distinction from most startups is that betaworks intentionally makes products that turn into companies, and its companies are held in a loose network, fostering learning and growth. Here, then is a short description of each of the phases:

  • Inception: this is closest to Lean Startup/MVP ideas, in that we try to have a single developer build out the core product use case end to end in a short period of time. What we do at the end here is some kind of assessment to determine if an idea is solid enough to make a bigger investment. In my talk, I refer to the origins of chartbeat, and while people gravitate to stories with clear beginings, most betaworks companies emerge from a primordial soup than a flash of divine insight.
  • Iteration: the next phase is also closely aligned to current startup thinking, and is where we start making rapid iterations and pivots, looking to pick off substantial and hopeful edge cases that were overlooked previously. If we think we have something - and often the market will tell us - we usually need to scale it up. Knowing when to pivot or completely change a business model is difficult, especially when so many startup narratives are about founders sticking to their vision. chartbeat is a clear case of this in that the underlying technology had origins in a real-time chat environment and ended up powering a data dashboard.
  • Scale: rapidly accommodating growth of a user base is often accompanied by corresponding growth in staff, the breadth and complexity of the app, and wildly spiking usage patterns. The betaworks network of companies share knowledge and experience with each other, so companies can move faster with fewer mistakes.

After my talk I was asked about the role of user experience at a startup and when to hire a UX person or team. The answer is, of course, it depends. My role at betaworks is pretty unique, in that I work across several companies at a time, and do almost everything (user research, interaction design, visual design, usability testing). I help companies grow, and to the point where they need to hire their own fulltime UX staff. To what degree a startup needs help with their UX (if at all) is dependent upon several factors:

  • The type of company. Some startups may be backend and/or API focused, and only need a simple marketing presence to communicate what they do. Other companies are completely dependent upon low-friction user interaction or cultivating user-generated content and might need more attention. bit.ly spent a considerable amount of time scaling up its infrastructure and refining its API, only paying attention to the UI later on.
  • Where in its growth cycle a company is. Generally speaking, I'd advise that companies outsource their UX for as long as possible (depending upon the above), since reasonably talented developers can get good mileage out of some good design patterns. Forming a close relationship with a single UX contractor can keep costs down while benefitting from gains in institutional knowledge.
  • The kind and level of UX involvement needed and is possible. The term "UX" is often misused and poorly understood (entirely through the efforts of its practitioners) but goes far beyond the appearance of a product. UX methods and solutions run the gamut from strategic to reactionary, from game-changing to decorative. A skilled practioner will be good or excellent in several areas, and wise enough to know what's good enough or when to call for help. A startup might not be willing or able to bring in user's voices to product develpment efforts, or choose to direct efforts in the wrong area. Having a designer make concepts "real" through lightweight prototypes or designs, and validating those with users can be far cheaper and time efficient than having a team of developers code up something. The nature of the business should indicate which paths to go down.

Overall, this was a great opportunity to deliver my perspective on how UX is valued and integrated into the startups at betaworks, and something I'll talk about more in the future.