Not the designer. Not even a coder. And yet you get excited every time there is a product related discussion. You are curious how the product will look like, how we are going to develop it and what stack we will be using. You feel more than ready to chip in every time there is a talk about customer behavior and understanding. You tend to keep a close look at the market. You worry that lack of focus might kill your product. You are spending your nights obsessing over these questions and writing detailed strategies to counter them. You are not the CFO but you work hard on the business model. You understand that lack of business will kill your product more than anything else. You don’t understand how to generate leads for sales but you care about the product messaging. If all these seem familiar than you are a product manager.

I have hated the term manager for the most part of my professional life—for the right reasons. The word manager has all sorts of bad stigmas attached to it. The one who has no idea what engineering team is doing and yet he wants to dictate their schedule. The one who has no sense of good design. And perhaps the most disturbingly, the one who does not even have a clear understanding of a company’s vision. Management for the sake of management is a bad idea. While most of your job is to oversee all aspects of a product you are managing, you can only do so if you understand and contribute some. You need to understand good design without necessarily having working proficiency of Photoshop. You need to understand code without being a master of shell scripting or Python. You need to have an understanding of your customer even though you don’t work in customer support. And you should know how your product will be sold without being the salesman.

Ben Horowitz puts it brilliantly in the Hard Thing about Hard Things.

Good product managers know the market, the product, the product line and the competition extremely well and operate from a strong basis of knowledge and confidence. A good product manager is the CEO of the product.

That entails everything. Just like being the CEO of your company means you are responsible for everything. The same is also true for a product manager. You are responsible for the product. Listen to Steve Jobs from 12:00 to 12:15 in the video below.

You are responsible for the whole package. You need to emphasize things which are important and let go of things which are not. You need to prioritize. You need to decide features that are going to be in the next version and the ones that will never be part of the product. To make these decisions you have to have knowledge of every facet of the product i.e. design, engineering, marketing, and customer.

Do startups need Product Managers? Yes. Ideally, one member of the founding team should take this responsibility. The title is not important because it’s an assumed responsibility not a designed one. There are two distinct challenges most startups face:

1. Most founding teams are young so they don’t understand all aspects of the business. Which is critical for product management role. Reading becomes instrumental if you can’t hire one.

2. Normally startup founders are either coders or designers. Or in worst, yet rare, case business people. If you are smart enough you will probably find a way to answer questions outside of Photoshop or Xcode. But it’s hard because unlike coding and designing it’s not a well-defined role. Business backgrounds are normally the worst because of way too much focus on the market than what makes a startup unique.

P.S. I liked the fact that Square uses Editors rather Managers as titles. The difference is profound.

For most of my professional life, I have felt torn apart between two ways to build a product. The YC’s and Paul Graham’s of the world told me to ship as fast as you can. The idea is to ship an early version of the product as soon as possible. Put it in the hands of the users and iterate over regularly. Since your product is in the hands of actual users and not in mockup testing lab; you will get the first-hand experience of how they are using it, potential areas for improvement etc.

From Paul Graham’s The 18 Mistakes That Kill Startups:

Several distinct problems manifest themselves as delays in launching: working too slowly; not truly understanding the problem; fear of having to deal with users; fear of being judged; working on too many different things; excessive perfectionism. Fortunately, you can combat all of them by the simple expedient of forcing yourself to launch something fairly quickly.

I always thought this is true for software and online services. And not so much for physical products. For one, hardware has a marginal cost associated with every iteration that is far greater than software. Because of these costs, you can’t roll out an update for free. Secondly, it’s hard enough to sell your product the first time. It’s even harder to sell them the exact same thing that is slightly better than the first one.

“If you are not embarrassed by the first version of your product, you’ve launched too late.”—Reid Hoffman, Founder LinkedIn

Also, for me, every business lesson is one way or the other an Apple story. I read the company too much. And Apple is, of course, famous for its attention to details. And not shipping anything until it’s perfect. At least that’s what I thought about them. I recently came across this wonderful post from Matt, CEO Automattic. It actually gets to the crust of this contention.

Many entrepreneurs idolize Steve Jobs. He’s such a perfectionist, they say. Nothing leaves the doors of 1 Infinite Loop in Cupertino without a polish and finish that makes geeks everywhere drool. No compromise!

I like Apple for the opposite reason: they’re not afraid of getting a rudimentary 1.0 out into the world.

…

I remember my first 1G iPhone. Like a meal you have to wait for or a line outside a club, the fact that I stood in line for hours made the first time I swiped to unlock the phone that much sweeter. It felt like I was on Star Trek and this was my magical tricorder… a tricorder that constantly dropped calls on AT&T’s network, had a headphone adapter that didn’t fit any of the hundreds of dollars of headphones I owned, ran no applications, had no copy and paste, and was as slow as molasses.

I never experienced the first iteration of the iPhone. But this is not something Matt is making up. The first version of the iPhone was not good. At least no way near to hint a business behemoth it would eventually become. And then there is the famous story that Steve Jobs was against having an apps store. Remember an iPhone without that and yet that’s exactly it was ten years ago.

Even more fascinating is the launch of original iPhone. Not only it was no way near as perfect as we attribute Apple products to be, it was full of bugs at the time of its announcement. The engineers had to arrange 5-6 different phones to demo different aspects of the phone. They have to make special network arrangements so that calls Steve made during the demo went as planned. The first-hand account of the event tells the story of crumbling background Apple employees as Steve created the picture perfect show we all remember today.

Any other CEO would have canceled the event. And probably would have waited for another year to launch the product. But not Apple.

So, shipping fast is the way to go. That’s how you build a great product, right? Yeah, except for one thing. From Paul Graham’s same essay:

Launching too slowly has probably killed a hundred times more startups than launching too fast, but it is possible to launch too fast. The danger here is that you ruin your reputation. You launch something, the early adopters try it out, and if it’s no good they may never come back.

So what’s the minimum you need to launch? We suggest startups think about what they plan to do, identify a core that’s both (a) useful on its own and (b) something that can be incrementally expanded into the whole project, and then get that done as soon as possible.

Now? How you know that you are not launching neither too fast nor too late? Expanding on what Paul suggested above, you need to listen to what your early adopters are saying. Are the problems they are identifying completely unknown to you? Or you anticipated them to a certain degree? You don’t have to be 100% right. But you should not be negatively surprised either. From Matt’s article linked above:

Now, the crazy thing about that release is when the original iPhone went public, flaws and all, you know that in a secret room somewhere on Apple’s campus they had a working prototype of the 3GS with a faster processor, better battery life, normal headphone jack… a perfect everything. Steve Jobs was probably already carrying around one in his pocket.

This is a bit extreme. But you get the idea.