Back to all posts

The Myth of the Design Studio Turned Product Company

How a remarkable story of a small design studio unwittingly drove an industry to madness.

37Signals successfully navigated the path of going from a design studio to being a software company. In the process of doing that they unknowingly started the mythology that every design or development studio should become a product company.

Early in 2005, as their first product, Basecamp grew in popularity something happened to the web development industry. The story of how Jason Fried and his team took an internal problem and built it into a massively successful product became the stuff of legends. It was a great story. Something we could all relate to. A small studio in a commercial neighborhood of Chicago was doing something that until then had been reserved for the innovators in Silicon Valley. It was captivating.

When Basecamp launched we were one of the first beta users. We had just started our web design firm Fresh Tilled Soil so it made sense for us to use the product. My business partner and I had signed up for a workshop in the 37Signals studio where Jason, Ryan and David talked about Ruby on Rails and UI patterns and thoughtful copywriting. They took the high ground and rallied against writing specs and adding features. During one of the workshop sessions an employee of Yahoo stood up and complained that product specs were critical to web application development. He raved on that spec writing was never going to disappear. Jason asked this guy what his job was. His answer brought the house down, “I write specs for one of Yahoo’s product teams”.

It seems like soon after launch they also started to realize they had done something unique and that was itself a great self-promotion tool. We ate up the story and they fed the fire. They published long detailed blog posts and books telling us how it was done. They ran workshops and conferences for the design community with the suggestion that we can all be product people. It was awesome. We drank the Kool Aid. We rushed back to our studios and started working on our own product ideas.

“Nothing was as important as building stuff that would long outlive the client projects we were working on.”

Some studios went to extremes. They dove headlong into the task of creating their own products. Their stunned clients stood by as their design and dev partners now shuttered themselves in and announced they would be working on their own products.

Almost every web app designer and developer felt unfulfilled. There was a restless energy in the service community. Their growth had been restricted by ‘time and materials’ billing models but now there was a pot of gold around the corner. Our hard earned product creation skills, honed on client projects, could now be used to unshackle us from the billable hour. Conversations with other studios were inevitably about “What product stuff are you guys working on?” Our venture capital friends came knocking. They asked what products we might have under wraps that might need funding. The message was clear;

“Unless you were creating a product that was going to become the next big thing you were wasting your time.”

Don’t get me wrong. What 37Signals did was amazing. I’m still in awe. But they messed with our minds. They distracted an entire industry from doing what they’re really good at — designing and developing great products on behalf of others. Without intent or malice, their adventure created a horrible myth, which persists to this day.

A small irony is that their story distracted the very people that they had created their tools for. Now their very customers were distracted from the tasks that made the tools necessary in the first place.

Since their terrific adventure hit the community every service company that provides design or development services has thought about branching into product creation at some time. Even Google’s 20% time policy encourages developers to tinker with their own ideas on company time. I have no idea if Google was inspired by the 37Signals legend but it’s certainly possible.

The mythology has reached us all and it’s now even part of our operational planning. At Happy Cog’s Owner Camp earlier this year it was on everyone’s lips. At the meeting of 22 design and dev shops “How do you make time for internal projects?” was still one of the most popular topics. The fact that this notion is still on the agenda in 2013 shows how powerful an idea it has become. There is now an assumption that all the agency and firm owners should all have an internal product strategy underway.

This week I was on a panel with several creative firm owners. Our moderator asked each of us how we manage capacity for client projects. My friend Sam Dunn answered that his company often plans their new project utilization around the 20% time that they allocate for internal projects. It’s not the first time I’ve heard that. Planning paid client work around unpaid internal products seems like a standard thing to do these days.

For a small design or dev firm 20% time is often the difference between profit and loss. If startups can’t produce guaranteed success even with all that support and a full-time effort, what makes us think that 20% of unstructured effort will get us? Even the most efficient and well managed studio would struggle to lose 20% of their billable time each year without a tangible return.

It’s possible that some of the risk could be reduced with a Lean or rapid-prototyping approach. But even with a Build-Test-Learn cycle there are significant infrastructure and resource hurdles to overcome. Building a product that’s good enough to charge for is difficult. In many cases it’s more than a full-time effort. And even then it’s hard to know if you’ll ever generate material returns from your new software product.

So what happened? Why did we fall in love with this myth? If it’s so awesome then why aren’t designers and developers rolling in piles of SaaS generated cash?

For us, the story of 37Signal’s success provoked us into believing a few fallacies. The first was that by working on a client’s product, we were making the client rich but leaving ourselves with the scraps. It’s a silly idea because even in the very rare cases that this might even be true the facts don’t substantiate this. Most startups won’t survive.

As mentors to TechStars, MassChallenge and other accelerators we’ve seen a lot of startups come and go. Their initial enthusiasm is often followed by waning cash reserves and one too many pivots. The reality is that only a small percentage of startups actually return anything to their investors. An even smaller percentage hit the big time. Being on the client side of the fence is way more risky than being the designer or developer.

A dangerous side effect of the myth is that as product designers we think we are automatically going to be good at creating products for ourselves. Not true. Building a product is hard. It involves way more than design and development skills. For one, the business models are very different and that means a whole new set of business skills.

Products don’t sell themselves. You might be a rockstar designer or developer but that doesn’t translate into business or marketing skills. Even if you’re supremely passionate and you’ve invested all your personal savings and hundreds of late nights to build a beautiful product it still might fail. Most founders expect early traction and growth but it’s just not guaranteed.

“You might be a rockstar designer or developer but that doesn’t translate into business or marketing skills.”

Even with all this knowledge we still can’t let go of the myth. There’s a gnawing part of us that wants to encourage our teams to tinker with internal products. It’s insidious. Being a great designer or a developer doesn’t seem to be enough for us.

We’ve convinced ourselves that we have to steal time from our core businesses to pay for a dream. When did we become so disillusioned at performing our beautiful craft?

The harsh reality is that having already experimented with several failed internal projects we’re pretty sure that giving 20% of our time isn’t going to be enough. Even when we spun out our ideas and brought on a full-time CEO and operations team we discovered that the funds needed to get to profitability would eventually bankrupt our core business. Finding the right people is extremely hard. Marketing and business development was even harder. Maybe we’re not smart enough to do what 37Signals did.

“There are no shortcuts to building a great business. There is no product nirvana around the corner for most of us.”

We’ve learned the hard way that focus is everything. There are no shortcuts to building a great business. There is no product nirvana around the corner for most of us. And that’s okay. In fact, it’s more than okay, it’s better that way. We need to stay focused on what we love and what we’ve become great at doing. Going deep on what we’re good at has generated far more ROI than nibbling around the product pie.

The more we dedicate ourselves to our craft the better we’ll be able to produce amazing work — even if it is for other companies.

“Learn the dedication and patience to gain an expert understanding of your passion. Become a domain expert.”

This week we launched an initiative that aims to ease the conflict between these opposing forces. Each of our team members gets to study a subject of their choice over the period of a year. It’s a long term study initiative that resembles a PhD. Think of it more like a thesis than project work. The purpose is to get them to think deeply about something that they are passionate about. We don’t expect them to build a product or launch a spin-off business. We’re not interested in getting distracted again. The goal of this initiative is simple; learn the dedication and patience to gain an expert understanding of your passion. Become a domain expert.

Obviously this will require time and money. But instead of investing in speculative ideas we’re investing in our people. Teaching our designers and developers to be more creative and discriminating thinkers seems to be the best investment we can make.

Since 2005 we’ve worked on over 500 projects. It’s an amazing body of work for a small studio. It’s given us the opportunity to work on a lot of very creative solutions for some amazing clients. Looking at our current and potential list of projects, the best is still to come. We’re pushing the boundaries on UX design and development. That feels really good. We’re proud of that work. I wouldn’t trade that for having to work on a single project for the next ten years.

I think the expectation that design and development firms should always be working on an internal product is madness. It’s time to remember why we got into the business of creating products in the first place. We love the challenge of solving problems. That’s a noble cause. If you do it well you’ll be rewarded. If you’re dedicated to your passion it’ll show in your work. Talented and fun people will want to work with you. You’ll fall in love again. You’ll even make good money. That should be enough.

“If you’re dedicated to your passion it’ll show in your work. Talented and fun people will want to work with you.”

As 37Signals releases yet another book and another great new product I’m reminded that I still haven’t got round to finishing my first book (update: I’ve now completed my first and second book). 37Signals and their leadership are truly productive and inspirational. Their business story is also a big distraction for a firm like ours. I’ll continue to read their awesome books and use their thoughtful products but you can keep mythology.

This post was originally published on Richard’s Medium profile.

Can we take you from stuck to unstuck?

We'd love to hear from you

Call to action (CTA)

A call to action is a marketing term that refers to a prompt that invokes a response leading to a sale. When referring to a call to action (CTA) in the digital design world we usually mean the interactive element that leads to the next step in the experience - something that needs to be clicked or tapped.

User testing

User testing refers to a technique used in the design process to evaluate a product, feature or prototype with real users. There are several reasons why you might want to undergo usability testing, the most common is that it allows the design team to identify friction in a user experience they are designing, so that it can be addressed before being built or deployed.

WYSIWYG

WYSIWYG (pronounced WIZ-ee-wig) is an acronym for "What You See Is What You Get". It helps identify an an interface that allows user input resulting in an output that is rendered in a similar way. For example; a word processor application interface might resemble a piece of paper,so when printed the user can see how the output will appear.

Content Management System

A content management system (CMS) is an tool that allows a website editor/administrator to manage the content that is displayed. Websites are made of HTML and CSS to create pages. Pages can be hard-coded but would require technical development skills to make changes. A CMS usually allows a person without coding knowledge to amend existing and add new content to a website using a WYSIWYG interface.

Responsive Web Design

Responsive web design refers to a web page that dynamically adapts its layout to fit the size and orientation of the device on which it is viewed. A responsive design allows for a more optimised user experience across desktop and laptop computers as well as smartphones and tablets of varying sizes.

User Stories

User stories allow the functionality of a product or service to be expressed as written descriptions of an experience as seen from the users perspective. The writing of user stories creates a list of design and development tasks to complete in order to create any required functionality.

User Interface

A user interface (UI) is a conduit between human and computer interaction - the space where a user will interact with a computer or machine to complete tasks. The purpose of a UI is to enable a user to effectively control a computer or machine they are interacting with, and for feedback to be received in order to communicate effective completion of tasks.

Personas

A persona in UX Design is the characterisation of a user who represents a segment of your target audience. On a project you might create any number of personas to be representative of a range of user needs and desires. The solutions you design must answer these needs in order to deliver value to your target audience.

Card sorting

A great, reliable, inexpensive method for discovering patterns in how users would expect to find content or functionality. Card sorting is used to test the taxonomy of data with a group of subjects, usually to help inform the creation of the information architecture, user flow, or menu structure on a project.

Brainstorming

A technique used to generate ideas around a specific topic. Often done in groups, but can be done individuals. The process usually involves writing down all ideas around a topic onto paper, a whiteboard or stickies often implying some kind of association.

Minimum Viable Product

An MVP is a product that has the minimum set of features to prove the most essential hypothesis for a product. Businesses building a new product can create a Minimum Viable Product to prove that an idea is viable and warrants further investment. A further benefit being that the next stage of development can be informed by feedback obtained from testing that MVP.

Sitemap

A sitemap is a diagrammatic representation of a hierarchical system. It usually depicts the parent-sibling relationship between pages in a website, showing how sub pages might be arranged underneath their parent groupings. This arrangement forms a map of the site.

User journey

A user journey represents a sequence of events or experiences a user might encounter while using a product or service. A user journey can be mapped or designed to show the steps and choices presented as interactions, and the resulting actions.

Prototype

A prototype is draft representation built to test ideas for layout, behaviour and flow in a system. Prototypes are an indispensable tool for resolving a large number of potential issues in a concept or business before too many resources are deployed to put a design into production.

Wireframes

A Wireframe is a visual schematic that conveys a basic level of communication, structure and behaviour during the design of a system. Wireframes are low-fidelity designs that bypass including a detailed user interface or visual design, conveying just enough to get across the core idea.

Usability

To say something is usable is a qualitative statement about how easy that thing is to use. Usability is an assessment of how learnable a system is and how easy a user finds it to use. The usability of a system or product is a key factor in determining whether the user experience is a good one.

Information Architecture

Information architecture is the design and organisation of content, pages and data into a structure that aids users understanding of a system. A more organised system enables users to more easily find the information they require and complete the intended tasks.

UI Design

User Interface Design is the discipline of designing software interfaces for devices, ideally with a focus on maximising efficiency, responsiveness and aesthetics to foster a good user experience.

UX Design

The practice of User Experience (UX) Design is the coming together of many specific design related disciplines to improve the usability, responsiveness, uptake and aesthetics of a product or service.

User Experience

A general term that covers all aspects of a user's participation while engaging with something that has been designed. Usually when talking about User Experience in the digital design field it refers to the interactions, reactions, emotions and perceptions while using an app, service, website or product.