The only role that software companies absolutely need to ship product are engineers. You need people to write and deploy code or there literally will be no product. It is a common pattern for companies to get off the ground with a pair of technical co-founders. While companies can ship product while only employing engineers, this leaves vast white space (see A Map of White Space for Product Managers). Developers can wear many hats, but ultimately companies need to enlist non-developer roles such as design or sales to optimally connect the product to users and a business.
Each role that a company adds brings complexity to the product development ecosystem. Natural tensions always surround a product as business and user needs tug in different directions. However, as dedicated roles are hired, the tensions become increasingly pronounced (see Tension in the Product Network). When the voice of a designer advocates for the user experience and the voice of a sales person advocates for revenue, elaborate communication becomes necessary to create a clear, actionable narrative for the development team and keep all team members aligned. Otherwise the company degenerates into some level of disarray.
An organization’s growing communication complexity poses a mounting threat to the simplicity of the product’s user experience and code base. Conway’s Law states that “organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.” The level of complexity in the product ecosystem is mirrored in the product. Some products scream to the world that they were designed by a committee of individuals who each had to put their own stamp on the product. This is not a recipe for shipping the Minimum Viable Product (MVP).
To control a product’s complexity, it is critical for a company to surround it by the minimum viable team (MVT); that is, the smallest number of contributors necessary to perform the diverse functions that a healthy product requires.
Here are two strategies in building an MVT and preserving the simplicity of the communication structure that surrounds a product.
1. Hire “full-triangle engineers.”
The product triangle consists of the fundamental elements that surround a product: the users, the business, and the code. A full-triangle engineer values understanding, in depth, all of these elements. Such rare individuals lessen the need to hire non-developer roles because they can fill in large white space themselves. E.g., for an early stage startup that is striving to validate a minimum viable product (MVP), the need to hire a dedicated designer is mitigated, if not eliminated in some cases, by a developer with sensibility for user experience and visual polish (this depends on the product).
Furthermore, by synthesizing the big picture dynamics of the company, a full-triangle engineer can produce breakthrough work with less communication overhead. The number of cycles necessary to translate user and business needs into clear engineering requirements is reduced by a developer who has the the product triangle dynamics internalized.
2. Hire product management as one of your first non-developer roles.
Product managers are particularly skilled at recognizing and filling the critical gaps around the product. It may ultimately be the case that the company should make hires to fill each gap, but having a versatile product manager is a way for the company to efficiently test which roles it actually needs before taking the complexity and risk of a new team member. In a sense, the product manager can serve as a prototype for each role such that it can be validated before fully invested in.
For example, a product manager may determine that web analytics is necessary to support the product design process. The product manager should be able to sufficiently own web analytics for the company eliminating the gap as a point of failure. If the product succeeds and the product manager becomes overwhelmed wearing the web analytics hat, then it’s time to hire a specialist.
Prematurely hiring a specialist perform a role that a product manager could perform sufficiently adds needless complexity to the ecosystem (and, consequently, the product). It could turn into a damaging distraction if it turns out the company doesn’t need the role after all (based on a pivot or misconception of the original need).
These two strategies will help you reduce the number of people working on your product which will translate into simplicity and an ability to react swiftly to external signal as a product twists and turns it’s way to validating the MVP. After the MVP is validated, it must, in some sense, become less minimal to grow. It needs to take on features or characteristics that were not necessary to test the idea, but necessary to support massive adoption. As the product becomes less minimal, the team will need to as well. The need to add specialists (e.g., analytics, SEO, performance, security) heightens.
But here’s the key: don’t move beyond the MVT until you’ve validated the MVP.
Product Logic 