Spare Me From “Product Guys”

Aaron Harris

Editor’s note: Guest contributor Aaron Harris is a co-founder of Tutorspree, the marketplace for tutoring. Follow him @harris, or take a lesson from him on Tutorspree.
We’re seeing people move away from finance and law and towards a culture of building things. It’s great to see more people seek careers in technology. The problem, I find, is that so many people approach the transition poorly. The first, and I suppose seemingly easiest claim and means to justify your place in the startup world, as someone who has no experience, is to call yourself a product person.
But that claim generally comes with a fundamental misunderstanding of what it means to do product. It is not code for a person who doesn’t really know how to do anything but thinks he can boss engineers around. It doesn’t refer to marketing guys who had an idea. Understanding what it means to drive a product means understanding the full scope of the vision of your company. It means understanding your engineering team, their capabilities, and their priorities. It means understanding what your next move is, and what your 6th move is from every angle.
And here’s my dark secret—a year and a half ago, I was sort of one of those “product guys.” I was still working in finance. I had big ideas, but had never managed product at a tech company. I’m sure I said a lot of dumb things, and there are definitely people who thought I was a schmuck. But, I had managed product for a group of 30 at the fund I worked for—so I had a sense of how to work with developers. I had known how to code at one point in my life (well, AP CS style, anyway). And, I think most importantly, I was very well aware of how ignorant I was (and, to be fair, still am).
Realistically speaking, there are certain people who will never be able to lead product of any kind. But there are also people who might be able to do it, if they worked on it, if they put the time and effort ahead of building their jargon. So, humbly, here’s a starter guide for learning how to do product (given some prerequisite imagination).
When I decided I wanted to lead product, I went and talked to friends who were product managers. If you don’t have friends that are PMs, try to stalk one on Quora until you can get a meeting. Make sure you have the questions you need to ask ahead of time. Pick their brains about what they read, how they think about feature design relative to user needs/wants/haven’t even thought abouts.
Realistically speaking, there are certain people who will never be able to lead product of any kind. But there are also people who might be able to do it, if they worked on it, if they put the time and effort ahead of building jargon. So, humbly, here’s a starter guide for learning product (given some prerequisite imagination).

• Read About Face. It’s big, it’s long, it can read slowly, but you’ll never look at a product in the same way.
• Read Design of Everyday Things. It will ruin your ability to walk through doors without complaining, but it will drastically improve the way you think about building anything and everything.
• Read Don’t Make me Think. It’s standard. It’s great. It is a necessary foundation.
• Learn to code. You don’t have to get good. You don’t necessarily have to remember the particulars of syntax afterwards. But you do need to remember the basics of how ideas become code and then become product. You have to understand why engineers work the way they do, why they love the puzzles that fascinate them. You need to have a basic understanding of what can and cannot be done easily. There are a lot of tools that can help you. I’d recommend starting with the very awesome Codecademy, and then moving on to a Computer Science Tutor.
• Keep reading blogs like Steve Blank’s, Marc Andreesen’s, and Paul Graham’s essays. Not all of them will strictly be about product, but they will help you learn to think.
• Ask questions of anyone and everyone with more experience than you. Keep asking them until your comfortable, and then find the things that you don’t know and ask more questions.
• Build.
• Screw Up.
• Build.

Even with this as a starting point, you’re never guaranteed to become great at product. But, doing this, I got a little bit better every day. More importantly, I was able to earn the trust of my co-founders Josh and Ryan that I’d make the best decisions I was able, and take the criticism when I screwed up.
So, “product guys:” nobody is going to believe you or take you seriously until you prove it. If you start talking about mobile local social software as a service (MOLASSES), you will be laughed out of the room. You are not, fundamentally, a product person until you actually build products. In order to get to the point where you can build products, you need to do a hell of a lot of work, and you need to iterate on your own knowledge.
You will need to understand that you are not the boss of an engineer, or superior to an engineer, simply because you think you have vision. If you are lucky, you will become a partner to a great engineer (or teams of them). You will be a member of a team where everyone has a valid say, but the decision will ultimately be yours. Your view won’t win out just because you talk louder or faster—it will win if it’s the right thing and you can back it up with logic, with experience, and with numbers.
So if you want to get into technology and don’t code, if you think you have a knack for product and a killer idea, start reading and learning. Then convince an engineer, as an equal, without blustering. Until you get there, you just have an idea. That’s nice, but it’s the very first step in a long road.
Photo credit: Shutterstock/Paffy

TechCrunch

Sphere: Related Content