Product Principles: Real Problems Cross Disciplines
Editor’s note: This is the second post in a six-part series from Levvel’s Product Innovation team that details the critical product principles the team lives by. You can read the first part here.
Think about an app, website, or electronic gadget that you love and why you love it. It could be that you love the usability of Airbnb or the value of Uber. Maybe you’re in awe of the engineering of the new iPhone or the magic of Amazon’s Echo. While each product might have its own highlights, what they have in common is that they all required successes by each of their respective business, engineering, and design groups in order for you to have ever noticed them.
One or two of these groups alone can’t launch a successful product. Take success away from any one group, and the whole product fails. Imagine Uber with no drivers, an Airbnb app that crashes constantly, or the beautifully engineered iPhone saddled with a totally unusable OS. These products might solve impossible technical or UX problems, but they will fail because they wouldn’t solve a real problem — your problem.
Real Problems
Simply put, a real problem is one that the customer is willing to pay to have solved. All other problems, technological, usability or otherwise, are in service of the real problem.
Working on large teams with typical management structures, it’s easy to substitute our own problems for the customer’s problem. For example, engineers might refuse to increase code complexity to meet customer needs. Businesses might choose boxed software for cost reasons over building the right product. Designers may be tempted follow the latest trends even when it doesn’t make things easier for the customer.
Traditional project management structures play into this trap by granularly separating teams and their concerns. The result is that individual teams win battles, but the product loses the war.
The “real problems cross disciplines” principle drives how we assemble our project teams, structure our processes, and hire new team members.
Team Structure
The best way to avoid the division of concerns is to create a team structure that encourages shared ownership and goals. I’ve previously written about how imbalanced teams produce predictable failure patterns. When one group has too much influence, the product ends up reflecting their goals instead of the customer’s.
At Levvel, we’re very intentional about the way we staff projects to keep focus on our clients’ problems, not ours. Each project is staffed with a cross-disciplinary team that includes a Senior Product Strategist, Technical Architect, and Product Designer. These core team members — representing business, engineering, and design, respectively — have equal responsibilities for shaping the process, setting the timeline, and collaborating with clients.
On a typical project, the three core team members contribute to every activity, including business strategy workshops, UX design, development, and post-release management. This process makes for more well-informed decisions throughout the project lifecycle.
This team structure also leads to more decision buy-in and ownership. For example, an engineer who was partially responsible for creating a business goal is less likely to push back on it during implementation — buy-in and ownership is massively important. In software, the productivity difference between a motivated team and a demotivated one is infinite.
Project Process
Traditional waterfall processes move projects through stages like “strategy”, “design”, and “development”. This makes it easy for teams to fall into the division-of-concerns trap, because only one set of problems is considered at a time and usually by a single group. Handoffs at each stage form invisible barriers between the teams. When we see handoffs happening in a project, it is a dead giveaway that the project is violating the “real problems cross disciplines” principle.
Handoffs Are Evil
Handoffs are evil for a number of reasons. First, they create a lot of waste. Handoffs mean excessively detailed documentation that takes forever to write and almost as long to read, if they ever get read at all.
Second, handoffs create communication gaps. No matter how detailed the documentation, some meaning will be lost in translation or disregarded altogether. In processes that include multiple handoffs, the noise adds up like a game of broken telephone. We’ve known since we were kids that the process reliably produces ridiculous results, yet many companies still run their development that way.
Most importantly, handoffs encourage team members to focus on intermediate deliverables rather than the real problems. You get what you measure, and a process riddled with handoffs most efficiently produces handoff documentation, not quality solutions.
Our cross-disciplinary process focuses on moving forward with prototypes and working code. We try to avoid intermediate deliverables as much as possible. We still believe that documentation is important, but putting the right documentation in the right place is far more productive than spending time polishing a strategy deck or red-lining a set of mockups.
Culture
Our discipline-crossing principle also affects who we hire. We interview a lot of great engineers and amazing designers, but not all of them are a great fit for the Levvel team.
Great Levvelers are usually people who cross disciplines. We love hiring designers who also code, strategists with Sketch skills, and developers with business acumen. The fact that they’ve picked up multiple skills is evidence of their drive to solve real problems and understanding that doing so requires multiple skillsets.
Employees with diverse skillsets make for great teammates. There’s immeasurable value in employees understanding adjacent disciplines; they must also be able to empathize with and respect their teammates. Working in an environment of mutual respect makes for happier, more productive teams and is the cornerstone of the healthy culture we’re so proud of at Levvel.
