Startup with Google

Google

Google has a new resource for anyone wanting to start a startup and it’s called Startup with Google. It targets founders and ranges from technical topics to best practices and even helps connect founders with accelerators and local events. Most of the resources focus on promoting Google services such as Android, Google Play, Google Analytics, Google Cloud, G Suite, AdWords, TensorFlow, etc. This is truly a pitch for startups to jump on the Google train and leverage as many Google services as possible. For some startups, this will make sense, but everyone should evaluate their needs before deciding to dive head first.

I like what Google is trying to do here. While it is self-promotion, it acts as a guide for startups. It would be nice to see this evolve and potentially include a logged-in experience for startups to register and be connected with organizations or other professionals. Right now, it’s basically a pretty collection of links. But, as Google states:

You’re out in front, we’ve got your back

So you want to be a product manager at a startup?

I hear a lot of people ask what makes a good product manager and I also hear a lot of people talk about how they want to be a product manager. The answer to the question and the response I give is the same…

It depends

There is no list of qualifications that ensures that Person A will be a good product manager for Company X. I have seen people with impressive resumes that have led successful product organizations at Company Z and Company Y and when they get to Company X, everything falls apart. It could be that they’ve become too accustomed to success and have lost the hustle. It could be that they didn’t understand the market or the users. It could be that the founders of Company X didn’t have a product that the market wanted. It could be that the founders didn’t let the product manager actually do their job. It could be that they assumed Company X should be run like Company Z and Company Y. And then there’s the possibility that Company X didn’t need a product manager. I’m a firm believer that Company X’s first/best product manager has to be someone who doesn’t have the title of product manager. In addition, they shouldn’t want to be a product manager – the company’s first product manager should be the user. Instead of paying someone to tell you what to do, ask the people who are paying you what you should do. And then do it, do it well and if that gets you more customers, keep asking the same person what to do next. If it doesn’t get you more customers, then go ask someone else. And if you don’t have customers, you new task is to stop looking for a product manager and go find some customers.

Okay, you’ve ignored what I’ve said and you want a product manager and therefore you want to risk hiring someone who looks good on paper and can talk about their successes. But unless you’re hiring someone from a direct competitor, they probably don’t know your market, your users, your product, etc. – with all those challenges, they’ll need the following:

Ruthless prioritization. Saying no to a hundred obviously good things to build the one or two most important things at any given time. Creating a culture of focus, execution, and agility.

Shepard. The product needs a Shepard as it passes from conception to design to engineering to consumers. Unable to prioritize a needed feature? Defend with data and supporting evidence. Development stalled? Find out what’s blocking.

Strong instincts. A good product manager will strive to get the product out the door as quickly as possible, but knows when something just isn’t ready for prime time and will be the one to say so. Good product managers are keepers of a great user experience.

And there’s a bunch of other stuff to look for (strong communication skills, good with engineers/designers, metrics-oriented, detail-oriented, etc.), but if you somehow can verify the above, I’m sure they can figure out the rest. And ultimately, good product managers figure out the rest.

What makes a good engineering culture?

A difficult question with no single answer. I do like a number of the traits listed in the following Quora question:

  1. Optimize for iteration speed
  2. Push relentlessly toward automation
  3. Develop a focus on high code quality with code reviews
  4. Build a culture of learning and continuous improvement

I really like the following description of what it means to be a team and what the objective of a software engineering team should be:

High quality software engineering is the product of a team. No one individual can be expected to deliver, nor take credit for, a successful product on his or her own. This gets fuzzy in small startups where there may only be one engineer, but otherwise holds true. A culture that celebrates one individual at the cost of another is making a grievous mistake.

There is an important distinction to note here about what comprises a *team* of engineers versus a group. The distinction is that a group is not a team until everyone in the group is committed the purpose [1]. In my experience, this commitment comes from inspirational leadership and transparency. The fact that an engineer is employed by a company is not reason enough to incite the determination, dedication, and thoughtfulness necessary to produce quality code. Committed engineers are engineers who are proud to work where they work and excited to talk about their jobs and their company’s products.

Ultimately, a good engineering culture is the result of a complex equation that includes the culture of the company, the objectives of the founders, the product being built and ultimately the first couple engineers. If you want to balance the equation, make sure you have product-engineering fit as well as product-market fit.