The Thin Line Between Creation

Last night, as I do most Sunday nights, I was catching up with all the shows I like to watch on Hulu. I wont bore you with the list, but lets just say that at least one includes a talking rabbit, another a talking robot, and yet another a barely talking human.

In between pseudo-Sorkin quips, I, as I often also do, was zooming through twitter. Most of the time, Sunday night twitter is full of football, random links to articles and really bad jokes (still not sure why Sunday is so devoid of humor). And in the midst of all of the noise was this tweet by John Meada:

Now John, who I have never met, is the type of person that you tell people you once ate breakfast in the next room, and were too afraid to ask a very good friend for an introduction (Scott Belsky, it was not me when we ran into each other at the Ace in NYC. Just saying.)

Former head of RISD, now a design partner at Kleiner Perkins and something big at eBay, John drives a lot of the thought in the design community. As a “product guy,” I tend to really think about the things he writes and says.

It hit me that John was not describing just visual designers. Yes, a great designer can take all the pieces of the product and the needs of the customer and bring them together in fantastic ways, but the product team needs to do the same with the needs of the customer and the elements of the feature set, and the engineers need to do the same with the underlying technology and the needs of the customer.

And, if that is true, that not just the visual elements are considered design, then the line between Product, Engineering and Design becomes thinner to the point of completely blurring.

When I stepped down as CEO to focus on product, I fully intended to build a traditional product/engineering/design organization.

Product makes; design creates and engineering builds.

But as we dove into it, it was clear that construct creates an imbalance of power reducing the necessary feelings of ownership and empowerment across the organization. Not to mention no longer reflect the realty of the internet itself.

While it is easy to simply dismiss this as the need for cross-training and whatever terms the MBAs of the world would dismiss this concept with, it’s deeper than that. For a product guy, the making of the product is sacrosanct. The battles I have had with product folks around features, customer research and the like have been seared into my brain. Designers and their distinct need to care about the curve of the letters, and engineers are no angels when debating frameworks, languages or button placement.

Traditionally, the PRD (product requirements document) was the document that ruled all. It clearly outlined each and every button and each and every action that would occur when that button was clicked. The designer would take that PRD and outline to the pixel where that button should live and to the shade the colors in each button state.

The engineers would often grumble about the difficulty of putting that button in that location and having it do that one thing, but they would do it, and lo and behold that feature would launch, and everyone was, well if not happy, at least satisfied.

But an interesting thing has happened. The weight of the product fell on the product team. Want to move the button? Ask product. Want it to look different? Ask product. Want to remove it? Don’t ask product. They will probably kill you.

Over the past month, I have tested the idea of not having product own, well, the product. What if instead of having one group own the product, we spread ownership across engineering, design and product, and empowered each to make product decisions. Want to move the button? Move the fucking button. But have a damn good reason.

Initially, it was an absolute clusterfuck. Engineers worked on what they wanted to. Design had little direction and product (well me), was getting crushed with managing product versus making product. But, suddenly over the last few weeks, things have started to gel.

The first thing I did was break the product down into clear components. The primary value was to allow management to understand how their decisions around sales and company direction affected the product and engineering effort. Want to close that deal? Cool, but then this wont get built. Want to drive in that direction? Alright, but then we need to spend time on building this.

(I understand thats standard product effort – but the difference was to break it into logical components, not features.)

Then once we made decisions around company direction, I sat down with the engineering and design team, and we worked through the prioritized product “pieces” to develop features and frameworks. From that we built a six month roadmap, and broke it into two week sprints. (Yeah, that stuff is all pretty standard.)

How do we deviate? If engineering wants to build a feature, they just build it. Product provides as much or as little direction as the engineer who is working on the feature needs. Same with design. Engineering becomes the leaders in product development. Product and Design are supportive.

What was the outcome? Well, there are features in the product I would have never thought of, and they are better than I would have ever come up with. There is certainly a bit more protective activity around key features and functions by the engineering team, but I’m ok with that. Design is able to work on future products and features, and Product (me) gets to be much more collaborative than I have ever been.

And, I don’t write PRDs (thank god). But, our engineers are evil overlords who force me to prove that a customer or potential customer wants the feature before they will add it to the roadmap. Damn them for making me do my job.

In today’s world, the products we build are organic. They cannot be built in silos, regardless of scale.

We must all be able to make product decisions that are substantial in order to build something significant.