ChangeOrder Moves to California
Slides from "Information Architecture: Making Information Accessible and Useful"

The Tipsy Triangle of Software Startupdom

Tipsy Triangle of Design Startupdom

In talking with entrepreneurs of many stripes over the past year, I've heard the following hypnotic refrain repeated over and over again: "If we design a beautiful user experience, we've got what we need to launch a successful business."

Whether uttered by corporate executives or designers fresh out of school, I've been surprised by this near-religious belief that great user experience is the silver bullet that will attract a huge audience base to your company's products or services. Surface solutions trump business plans. To quote Enrique Allen, founding member of The Designer Fund—a community of designers that invest in designer startup founders (of which I’m a member):

“UX can be a 'grabber,' like the shiny materials we buy but then don't end up using after a few days. Without a solid tech and business model 'holder' that provides lasting utility, startups will peak but then crash…”

Yes, to your customers, the user experience (UX) is everything: it's how your product or service is utilized by the world. But if you are a designer trying to create a sustainable business from your product and service ideas, the UX for your product is one important facet of creating a successful business. The user experience you design, the technology selections you make, and the business model you generate: all of these decisions support how you make money from your products and services. They are interrelated, to the point that you can't truly sustain a business in the long term without them all in place.

This may be obvious advice for those who have spent time creating products and services, or worked at a startup before. But for any designer that is looking to jump into the software game and bootstrap their own products or services, closely consider the following perspectives in the early stages of any new business venture.


Are You Going into Technology Debt?

I wouldn't call myself a technologist, but in working with them closely over the years, I've discovered that just as designers make well-informed choices to generate a compelling design, the quality of the decisions any startup makes around technology can have a dramatic impact on their success. These choices include what solutions you develop internally, what platforms you utilize, what data you draw from third-party services, and what infrastructure (such as hosting) keeps things running smoothly in the long term. It's never enough to launch your product or service—you have to sustain it. “Decisions you make early affect your technology DNA,” says Enrique Allen. “Shipping crap will eventually build up as technology debt.”

Many startups fail when they dive deep into IT rather than realize that it isn't (and shouldn't) be a core competency. Even perceived successes such as Twitter or Facebook initially struggled due to weak technology platforms, which cost them credibility until they could stabilize themselves. Any startup must consider the time and expense of devising their own technology solutions, and regularly evaluate whether their efforts can be quickly duplicated or improved upon by others before they release their creation out into the wild. If you invest the time and energy in building your own code base for delivering a service, or set up your own hosting to drive your business, you're making an investment in your technology infrastructure independent from how it's provided by your partners and other third parties. At a fork in the road, your startup may need to abandon its homegrown technology solutions to adopt a more cost-effective one provided by a partner, while attempting to retain whatever key inventions or services give your businesses its "secret sauce."

If you don't have your own "secret technology sauce," there are plenty of people out there that seem to proffer them. In a world where it doesn't take massive effort to prototype a website or cobble together an iOS application, we have a vast swath of technologies at our disposal for building next-generation UX on existing platforms or trying to generate our own. Add to that the multitude of APIs provided by third parties, and we can mix and mash up data to our hearts content, constructing new recipes for novel products and services.

However, this is not an idyllic dream world of technological unicorns and rainbows. In this playground of possibilities, we can be held hostage by the changing constraints of those platforms, technologies, and back-end services. One of my co-workers and an Associate Technology Director at frog, David Phillips, described today’s situation to me as when desktop publishing became the rage. Once authors could bypass the editorial process and provide their work directly to the populace, there was a flood of poorly considered publications. In short, he said, “Having the tools doesn't lead to superior use."

If your online product or service idea requires utilizing someone else's technology platform, then you are assuming that company's long-term risks. This was underscored in Farhad Manjoo's recent article "The Zynga Conundrum" in October 2011's Fast Company magazine, where he noted that being dependent on other people's platforms is like being a barnacle on a ship: "there can be a quick buck in being a barnacle…. though, the success is short-lived, because barnacles have no say in where the ship is headed." He uses Zynga as a case study for a business that draws $600 million dollars from the use of its games from a social network it doesn't control. You can ride this train, but you have to know when to jump off, and hope you don't get bruised in the process.

Beyond building off a third-party platform, you can also assume risk just by using third-party services to drive critical features of your product or service. For example: You could create a camera recommendation service for people that utilizes the Hunch application programming interface (a.k.a. API), which would allow you to provide recommendations drawn from their extensive database.

It takes a non-trivial amount of effort to build this kind of recommendation service, so partnering with Hunch sounds like a great idea, right? Designers shouldn't be afraid to partner with other businesses in this manner—but you need to know exactly how much risk you are assuming by utilizing their services as part of yours. If Hunch were to go out of business, your product or service won't function unless there are equivalent services available for the same cost—and even then, you'll likely have to redraft some portion of your back-end services to work with the new service. To quote David Phillips: "This is partly a matter of architecture as well. One of the main advantages of abstraction layers is to control such risk. You may have to refactor an API, but you protect your core code base at the same time. There are some sacrifices to efficiency and performance—but hardware is cheap compared to the time spent rebuilding major parts of your product."

The same thinking goes in using a pre-existing framework for your front-end development efforts: the platform that you select can free you from a lot of heavy lifting, but at the long-term cost of dragging you down or forcing you to re-develop the same code base independent of that framework. The rallying cry around HTML 5 and open standards isn't just for convenience and continuous improvement—it's to help us create products and services that can be more easily deployed across platforms. (Wonder why so many web designers and developers have been beating up Adobe Muse?) In at least the near term, you'll still have to choose between native and web-based solutions for your products and solutions—risking an investment in more performant UX versus device/platform portability.

As you may have intuited, the way you construct your product’s UX can be more susceptible to market and technology timing than you ever thought possible. So how does a designer make good technology decisions in an ever-shifting technology landscape? Identify co-founders with deep expertise in technology that can help support a startup venture, bring in advisors that can provide you with the right perspectives, and consider partnering or pairing with a community of startup designers that can help support you through the first iterations of your product or service.


Who Will Pay to Use Your Great Product?

Designers often have amazing, beautiful ideas that need to be brought into this world. But only a select subset of them will ever make money for the designer, and an even smaller subset of those products and services will be able to sustain themselves. The latter have the following characteristics, which divide passion projects from sustainable businesses:

  • People want to use those products or services, as they fulfill a perceived need
  • Someone wants to pay for those products or services to be around (this isn't always the people who use the product or service!)
  • There aren't many other people doing what you do, but you see an emerging or established behavioral pattern you could support

If you can't clarify how these characteristics are addressed by your startup, you are assuming around your business model.

Let's return to my example of the camera recommendation service we were going to build off the Hunch API. Is this an idea for a product or service, or just a well-constructed content site (a.k.a. blog)? Can you beat, Retrevo, or B& at their own game? Is this something Google or Bing has already baked into their search engine?

You might think, "Forget the competition—let's just give it a try with a small release! People always struggle with finding cameras. Those websites will pay you for traffic to their site—especially if they're ready and willing to make a purchase. Let's just put it out there and see what happens."

I'm a fan of taking risks when it comes to bringing an idea into the wild—but those risks should be calculated. Other people may already doing what you want to do. You should use simple math to work back from the amount of time, money, and people you think the service would require to run at a slender profit margin, at different scales. If the math doesn't prove out, then you should consider a new business model, technology choice, or starting over with a related (or new) idea. Enrique Allen says, “Creating a baseline model is critical. Input your assumptions before you launch, so you can see if your hypotheses hold true.”

Supporting that new business model may take methodical planning on your end. Instead of the above scenario, imagine you've worked with a developer to create your own back-end service that lets you draw from and select the best information from various public-source APIs. (There is strength in intelligent recombination of existing services, as creating new services and sources of data can be prohibitively expensive.) You decide to make money by referral fees to other websites, and directly negotiate with them to achieve more favorable rates. You've created what you believe is an effective UX for it. Then, you put it out into the wild as a beta release.

You may have lost some time in getting your product or service out to market. But you may be in a much better place to get traction on a customer base that can make your business sustainable in the short- to mid-term.

A side note: venture capital can help startups circumvent these issues, but only until they see they’re about to run out of "runway" before they’ve determined how they can shift the onus of payment from the venture capital to paying customers, related businesses, or third-parties that want to leverage their customer base in unique ways (including data mining or building services off their APIs). Or, perhaps a larger company that wants to own their technology platform and user base for their own purposes—an exit strategy that doesn’t always play out how founders might expect.


When Well-Intentioned Startups Get Tipsy (and Fall Down)

Let's go back to the diagram at the start of this piece. Now that you understand how technology choices and your business model factor into the stability of your startup idea, you can see how a business can flop rather than grow in the long term if there isn't a solid foundation.

If a business has a strong business model and good UX, but was built on a poor set of technology choices, it can suffer or die when a critical piece of infrastructure is yanked out. To flog Twitter: it took an eternity in Internet time for them to get the platform more stable in terms of uptime. If they hadn't fixed this, it's unlikely they would ever have had a chance. Can you imagine only 80% of your SMS messages to your friends going through from your phones? 90%? Customers will only tolerate so much.

If a business has made smart technology choices and has good UX, then it has a better chance of attracting and sustaining a user base. However, there may be no hope for the product or service to make money in the short- or long-term if their business model is flawed. It's hard to start a business by losing money with every transaction. (Remember from the web boom?)

And if a business has a great UX, but no stable technology behind it or thoughts regarding a sustainable business model—I think you get the picture.

If you're looking to create a startup, consider these three elements and how they balance each other out. Make sure you don't lose focus on how your long-term success is determined on the interrelationships between these three elements, not just any one of them. Don't be afraid to find the right people and partnerships that bolster your weaknesses in any one of those areas, so you can more quickly gain traction with your ideas.

Enrique Allen says, “Balancing UX, tech and your business model will always be at tension for priority, and it's up to the founders to synchronize them in harmony and sometimes focus on only one area.”

And be ready to shift your priorities when moving from idea into implementation. David Phillips says, "As an idea scales, things get bigger. They not only have more inertia, but they become far more costly to modify. On the technology side, scaling usually means creeping toward a more waterfall model, while the vitality of a UX will likely continue to depend upon rapid iteration." For this reason, build time into your schedule to regularly back away from designing the minutae and assessing the big picture. This will help you navigate building tension between your beautiful design work and the foundation that supports it.

Have any opinions on what it takes to sustain a designer-led software startup? Leave them in the comments!


The comments to this entry are closed.