4 Ways Your Startup’s Business Design Decides Whether Your Product Succeeds or Fails

I like to read, love to learn, and know that part of becoming and staying good at what I do means staying up on what’s new in the startup world. As a consequence my inbox is filled every morning with newsletters, daily digest emails, and the like providing me with approximately 121,000 words of new reading. Despite this daily firehose of new stuff, I try to remember that sometimes it’s also worthwhile to read some stuff that’s more than one day old.

People have been writing computer code for more than 50 years and studying the way people work together in businesses for a lot longer than that. Mel Conway has been doing both since 1956, and in 1968 he published a paper named “How Do Committees Invent?”. The conclusion of that paper contained a sentence that gained fame as “Conway’s Law” when cited by Fred Brooks in The Mythical Man Month. It reads:

“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.”

A simple interpretation of this is that when designing a new system, people will consciously or unconsciously model it on a system they are already familiar with, such as their organization. It takes intent and discipline to step and stay outside of your own frame of reference. But if we dive deeper, we find that Conway’s Law presents a unique set of risks/opportunities for organizations building software products. Here are four implications of Conway’s Law that every startup should understand:

  1. You start making UX decisions before you know you are making them. Picking a programming language, delivery method, or development structure for your startup before the requirements of your product are know is just as dangerous as spending time picking out fonts and button colors before you’ve tested your UX. Every choice has built-in tradeoffs, and you need to understand what you are setting out to build and how those tradeoffs will affect it before you commit to anything.
  2. How your product teams are structured directly affects how your product works. How many times have you used an app that gets updated regularly but still lacks a feature that its users clamor for, or stubbornly enforces a workflow that makes little intuitive sense? This is a dead giveaway that the UI/UX team and the Development team aren’t talking. Each one is trying to design their part of the system to work as well as possible, but they aren’t coordinating with each other, which means workarounds, kludges, and features that can’t be implemented without ripping out vast swaths of code or UI resources.
  3. The success of your startup’s product depends on how well your Designers and Developers work together. The only sure-fire way to make sure that your product avoids the trap of an incomplete and confusing UX is to build cross-functional communication into your team from the ground up. Developers should be working with UX and UI Designers to define workflows and wireframe interfaces, and Designers should be sitting down with Developers to work through roadblocks or take advantage of opportunities uncovered as the code is developed. In other words, if your Designers and Developers work as a single, cohesive team, it will show in the clarity and usability of your product’s User Experience.
  4. Product development is a circle, not a line. No more “throwing it over the wall”. Even informally dropping by your coworker’s desk isn’t enough by itself. All members of the team need to be involved in all phases of the product’s development. Not all at the same level, but your Developers need to be in the room in the earliest stages of defining the product, and your Designers need to be at development team stand-ups regularly. Whether your startup uses waterfall, Agile, or Lean, the product development cycle is just that — a recurring pattern of work, and the lessons from the last cycle need to be internalized by the people kicking off the next one.

One final bonus

Conway’s conclusion also reminds us that “Because the design which occurs first is almost never the best possible, the prevailing system concept may need to change. Therefore, flexibility of organization is important to effective design.” Your startup needs to be capable of changing your process and structure to meet changing needs of your customers or the market.

With this in mind, defining job roles by skills rather than desired outcomes will work against you.

Everyone asks “should designers code?”, but this goes deeper. Your team members need to know enough about what everyone else is doing that they know how their work depends on and is depended on by everyone else’s. You also need to make sure they all understand the business objectives behind the project, and give them the freedom to decide how best to achieve them. This will make everyone in your organization see the need for change sooner and will give them the tools to make those changes more quickly without getting stuck in a bureaucratic morass. It will make your startup more responsive to change and get everyone on your team in the habit of seeing opportunities for innovation.

Interested in more?

My article “Design is Building a Business: UX Design Principles that will Transform Your Company” goes into the details of structuring your business around a cohesive User Experience and Business Experience Design, and if you subscribe to the dbdc Newsletter you’ll receive a free white paper containing three real-world case studies, highlighting tools your company can start using today to benefit from the lessons learned. Download it here.


Originally published at Denver Business Design Consulting.

Show your support

Clapping shows how much you appreciated Jeff Daigle’s story.