Learning Slows You Down

Yet I spent all of last week working on product. I do not code, but--in keeping with the promise and insight of WithoutCode--you and I both know that I do not have to.

In the past, I used the fact that I could not write code as an excuse for not taking ownership of my own company's product. I did not prefer this; I just thought that I had no choice.

I founded the company. It was my vision. My entire team looked to me for direction. But when it came to product, they knew better than to rely on me.

I have worked with many "product people," in my case, all of them engineers. If I am being gracious to myself, then I might say that I was like Steve Jobs: I (thought I) knew what I wanted the product to be, and I saw it as my job to simply hand that vision over to the product team for implementation.

If I am being honest, though, then I would say that this hand-off model is inherently flawed.

One does not hand-off product. It does not actually work that way, and anyone who thinks that it does is due an eventual reality check. Reality check is a good term here, because it is the opposite of reality in which all optimism in the hand-off model must hide. Once reality creeps in, something must die: either your optimism or your honesty.

I will not attempt generalizations. Instead, I will just tell you about me. This is why non-tech people like me--the former me, that is, the one who did not always know how to build apps without code--annoy tech people.

• I oversimplified the process of iterating on a product
• I underestimated the depth of preparation on which a product iteration should depend
• I failed to see that asking product people to simultaneously wear several hats--marketing, sales, strategy, et cetera--slowed them down
• My inability to code dictated an iteration process that did not allow for quick, decisive learning to take place

About that last point, let me give you an example.

Two hundred years ago, the speed of collaboration was subordinate to the speed of communication (this is still true today, of course, except that now the speed at which we can communicate outstrips the speed of collaborative deliberation; so today, communication waits on deliberation). When Thomas Jefferson was president in 1801, for example, he had the postmaster general devise a special mail route between Washington D.C. and Monticello, Jefferson's mountaintop estate in nearby Virginia. At its fastest, letters could arrive in Monticello two days after leaving D.C., and letters to D.C. from Monticello in a week. Thus, the max speed of any collaboration between Jefferson at Monticello and anyone in D.C. was about nine days per necessary exchange. 

Given these constraints, what do you suppose President Jefferson did? He had two options. He could either resolve to accept slower collaborations--which, relative to today, he certainly did--or he could limit the number of exchanges he deemed necessary.

When you are the non-technical leader of a product team, as I once was, your inclination is to suppress the number of exchanges you deem necessary. You avoid digging deeper into the details because you fear that you might not even understand them anyway, and, more importantly, because you do not want your steep learning curve to slow down an otherwise capable product team. The problem, then, is that the person to whom the product team looks for cues is the person least familiar with the product details.

The other problem is that, by discouraging your product team from bringing these details to you as they uncover them, you are actually engendering an iteration process in which learning itself is discouraged. You might, for example, dictate a product vision to your team based on the assumption that the world is flat. Then, in the course of that iteration, when your product team discovers this to be a flawed assumption, they have to choose between bringing you that detail and just keeping pace on the original build plan. If you create a system of iteration that accommodates your handicap, then you might convince yourself and everyone else that the metrics that matters most are only the ones that you are capable of understanding, like pace of build and adherence to the original plan. This, of course, is bad, as is anything that systematically discourages learning.

And this is why I think I used to annoy my technical collaborators. I thought that averring anything I deemed too technical to be perfectly appropriate for a non-technical person like me. They, on the other hand, probably saw me as someone who lacked respect for learning, even if it was necessary.

This is not unique to engineers. You hear this sometimes when you encounter someone who does not speak your language: people appreciate it when you try to speak their language, and in many contexts, they might resent you if you give the appearance that you do not care to try.

Last week, I headed up my very first product sprint in which I assumed all roles. Yes, I was the vision guy. I was the marketing genius who thought he knew something about what people wanted. I was the scrum guy who mapped out the sprint schedule and assigned tasks (all to me, though). But then, once all of that pomp and presumption resulted in something that needed to be built, I had to actually be the one to build it--made possible, again, by my recently acquired skill of building apps without code.

Here is the most important thing I learned from my first full-contact product sprint. Every time the sprint requires input from a different role (i.e. marketing, sales, et cetera), the pace slows down. This is because, unlike the old me who thought that it was good enough that I just get my ideas on the board so that everyone else could bask in them, the new, WithoutCode me knows that any idea that anyone puts on the board needs to be vetted (or not) and then absorbed by everyone working on that iteration. So, non-techies, that means no more drop-the-mic contributions to product sprints that you do not even care to fully understand yourself.

But in general, since I wore all hats during this sprint--something that building apps without code makes uniquely possible--I learned that the thing that slows it down the most is a commitment to learning. If you are committed to learning, then you capitalize on opportunities to learn something, when you are fooling around in the lab and your product sprint reveals those learning opportunities to you.

The cool thing about building apps without code, in my case, is that my first claim-to-fame was not product. I was good at sales, marketing, and a number of other key business functions that informed me about what should be built and why. Now that I have added the ability to actually build the products I envision, that in-sprint learning process is so much more intricate and valuable. I do not have any sort of role-specific blinders.

This full-stack-founder ability is both what slows the sprint down and makes it an exponentially more valuable exercise.