Arriving at a company as a new (or sometimes, the first) Product Manager can be daunting. Product Management is usually introduced in an organization once there is a such a high level of internal enthusiasm and chaos that the leaders aren’t sure how to handle it any more. And then everyone looks to the Product Manager — you — to “manage stuff”.

It’s easy to get overwhelmed by how much there is to do when you step into a stressful role like Product Management. So here are some recommendations on how to spend your first 3 months at a new company.

First 30 days: Understand the product, the market, and the company culture

The goal of the Product Manager is “to deliver measurable business results through product solutions that meet both market needs and company goals”. With that in mind, spend the first 30 days learning and understanding:

• The product. What does the company sell? What does the product do? How does it work? What is the value proposition? What problems does it solve for customers? What features does it have? What kind of bugs does it have? What are the main usability issues?
• The market. Who currently uses the product? What are they like? What are their characteristics? What do they like and not like about the product? Who is the target market? Are there personas for each different type of person in the target market? What are macro and micro market needs addressed by the product? Who are the competitors?
• The current product/market fit. Are you in a good market with a product that can satisfy the market? What are the gaps that you need to close between what the product does, and what the market needs, to ensure a better fit?
• The company culture. Talk to as many people as possible in the organization — from marketing to finance to design to engineering — to understand how things work. What do people like about the product development process? What do they hate? Do designers feel like they have enough time to do their work? Do developers have what they need to program effectively?
• Ensure the PM role is properly understood. For a Product Manager to be effective, the organization needs to understand that PMs should have autonomy over the products they manage. Executive buy-in is a prerequisite for success, so make sure that it’s well understood that even though everyone gets a voice, not everyone gets to decide. As Seth Godin once said, “Nothing is what happens when everyone has to agree.”

Next 30 days: Develop a strategic product plan

Based on what you learn in the first 30 days, start the product planning phase:

• Run a Product Discovery workshop to start identifying user needs, business needs, and technical needs, and to create a problem frame diagram.
• Develop personas and user journeys, and start brainstorming ideas for product development with the team.
• Work with the team to prioritise ideas and start building a roadmap for development. Consider methods like the KJ-technique or the Kano model as a way to formalize prioritization efforts.
• Identify success measures — define how you’ll know if what you’re doing is having the desired impact. The 3 A’s (Acquisition, Activation, Activity) are always a good start.
• Put the appropriate processes in place to ensure effective product development lifecycles. This means knowing what kind of requirements and specifications developers need to start working, how research and design fits into the process, where marketing becomes involved, how QA should work, etc. You can only do this once you understand the current culture, and what the strategic plan will be going forward.

All of the above goes into a document called the strategic product plan. Among other things, this plan includes statements about the product’s value proposition, who the market is (customer profiles), how you plan to achieve product/market fit (the business opportunity, pricing, distribution), what the priorities are, a first stab at the roadmap, and proposed success measures.

Next 30 days: Start executing on the strategic product plan

Now that the plan and the initial roadmap are in place, start the product execution phase:

• Start with a reasonably small requirement with clear and easily measurable success metrics. Work with the team to get it done right.
• Measure, and show the success of the process. Use this to build trust and continue to ship improvements (and even better products).
• Assess the situation, and use customer and business feedback to adjust priorities (and the roadmap) as needed. Flexibility is key.
• Keep going. Repeat any of the initial steps as needed.
• Have fun while you’re doing all of this.

The life of a Product Manager has an exhausting, exhilarating rhythm that is beyond the scope of this article. But spending your first 3 months systematically moving from product planning to product execution will not only give you a solid foundation from which to improve the product, but also ensure that you hit the ground running by shipping the right improvements as early as possible.

I posted an earlier version of this article as an answer on Quora.

Peter Matthaei wrote down some thoughts on failure, startups, and product development in ALL THE USE CASES. He makes some good points, like this one:

Every great company started by being great at solving just a single problem. Quite often, a very humble one. But they solved that one problem incredibly well, picked up momentum, and with large doses of relentless ambition, good timing, vision and luck kept on going.

Dropbox is, of course, the poster child for this line of thinking. One of my favorite Quora answers is still Michael Wolfe’s response to Why is Dropbox more popular than other programs with similar functionality?:

“But,” you may ask, “so much more you could do! What about task management, calendaring, customized dashboards, virtual white boarding. More than just folders and files!”

No, shut up. People don’t use that crap. They just want a folder. A folder that syncs.

I would add that I think the problem with most startups is not necessarily that they’re trying to solve too many problems; it’s that they’re trying to provide solutions to problems that don’t exist. I love this quote from Pragmatic Marketing in their post Who Needs Product Management?:

It is vastly easier to identify market problems and solve them with technology than it is to find buyers for your existing technology.

My thesis continues to be that the single biggest cause of startup failure is focusing on finding buyers for cool technology, as opposed to identifying (and fully understanding) market problems first.

Steve Cheney wrote an excellent analysis of Facebook’s new search tool in Graph Search’s Dirty Promise and the Con of the Facebook “Like”. The problem? Most “Likes” on Facebook are bought by ad agencies, not earned organically. The result:

One direct effect of all this passive liking is an ugly messy data set with a bunch of implicit signals… that are wrong. What happens when your girlfriend types in “restaurants in San Francisco” into graph search and P.F. Chang’s gets spit out because it’s the most-liked restaurant.  Was a bad Chinese chain the kind of serendipity you were looking for on your date? Didn’t think so. 

I also like Ariel Seidman’s take on the challenges Graph Search will need to overcome in Can we make that search box bigger?:

Consumers think in terms of I got a job to do. What product will I hire to do this job? For restaurant searches I hire Yelp. I need a flight to Chicago I hire kayak. I need to start looking for jobs I’ll hit LinkedIn or Indeed. Each of these have their own experience, community, privacy expectations, and detailed data. As BranchOut has shown people do not want Facebook to be the place to manage their professional life, they have hired a different product for that job.

I know I tend to be too skeptical about this kind of stuff, but Graph Search just strikes me as another solution in search of a problem that doesn’t exist.

Derek Powazek pulls apart the saying “If you’re not paying for the product, you are the product” in his post I’m Not The Product, But I Play One On The Internet. His conclusion:

We can and should support the companies we love with our money. Companies can and should have balanced streams of income so that they’re not solely dependent on just one. We all should consider the business models of the companies we trust with our data.

But we should not assume that, just because we pay a company they’ll treat us better, or that if we’re not paying that the company is allowed to treat us like shit. Reality is just more complicated than that. What matters is how companies demonstrate their respect for their customers. We should hold their feet to the fire when they demonstrate a lack of respect.

This is, of course, in response to the Instagram TOS debacle, which resulted in an update from Instagram to clarify their terms in a post with the “please stop shouting at us!” title Thank you, and we’re listening. But as Faruk Ateş points out in What Instagram did wrong:

Bad language is merely a symptom of the bigger mistake they made. Their failure lies in not acknowledging—or understanding—the change in expectations that took place amongst their users when they sold themselves to Facebook for a billion dollars. […]

Once you sell to a frequently-criticized juggernaut like Facebook, users’ expectations change from supportive to skeptic, and, especially because of Facebook’s long history of privacy-related mishaps, you may very well lose all benefit of the doubt amongst some of your users.

Oh, how many PR disasters could be avoided if companies would learn to respect their users, and be more in touch with their needs and goals…

Here’s an important reminder that tools don’t matter as much as we think they do. What matters is how the tools enable people to accomplish their goals. From Chana Joffe-Walt’s Why Legos Are So Expensive — And So Popular (my emphasis added):

But Lego did find a successful way to do something Mega Bloks could not copy: It bought the exclusive rights to Star Wars. If you want to build a Death Star out of plastic blocks, Lego is now your only option.

The Star Wars blocks were wildly successful. So Lego kept going — it licensed Indiana Jones, Winnie the Pooh, Toy Story and Harry Potter.

Sales of these products have been huge for Lego. More important, the experience has taught the company that what kids wanted to do with the blocks was tell stories. Lego makes or licenses the stories they want to tell.

No one cares about your product as much as you do. But they do care about their stories. And understanding that can help you make better products.

Speaking of Ryan Singer, I recently re-read his answer on the Quora startup thread Should I focus on a good user experience, or push something out quickly? He makes a really good argument for investing in design very early in the product development process:

Design is a path-dependent process. That means the early moves constrain the later moves. On the very first iteration the design possibilities are wide open. The designer defines some screens and workflows and then the programmer builds those. On the next iteration, it’s not wide open anymore. The new design has to fit into the existing design, and the new code needs to fit into the existing code. Old code can be changed, but you don’t want to scrap everything. There is a pressure to keep moving with what is already there.

Our early design decisions are like bets whose outcome we will have to live with iteration after iteration. Since that’s the case, there is a strong incentive to be sure about our early bets. In other words, we want to reduce uncertainty on the first iterations.

This is why variation, not just iteration, is so important during the early phases of a product.

The Economist has a fascinating piece on what makes Samsung’s strategy so effective. From Samsung: The next big bet (my emphasis added):

Samsung’s successes come from spotting areas that are small but growing fast. Ideally the area should also be capital-intensive, making it harder for rivals to keep up. Samsung tiptoes into the technology to get familiar with it, then waits for its moment.

When it pounces, the company floods the sector with cash. Moving into very high volume production as fast as possible not only gives it a price advantage over established firms, but also makes it a key customer for equipment makers. Those relationships help it stay on the leading edge from then on.

The strategy is shrewd. By buying technology rather than building it, Samsung assumes execution risk not innovation risk. It wins as a ‘fast follower’, slipstreaming in the wake of pioneers at a much larger scale of production.

This is in direct contrast to Apple’s strategy, which is to look for a mature, stale market, and then innovate to deliver a solution that’s several orders of magnitude better than what incumbents are selling.

Dan Lyons gets to the heart of the Instagram/Twitter spat in Instagram Turns Evil, And It’s All Our Fault:

Companies like Twitter and Instagram (and Facebook, which owns Instagram) are set up in such a way that their interests have never been aligned with the interest of their users, but in fact are in complete opposition to them.

The only way these companies can succeed financially is by tricking members and forcing them into walled gardens. Think of it this way - there’s a reason that they don’t hold a circus out in the open, and instead put it under a tent - and it’s not to keep you dry in case of rain.

Dan is saying this is all our fault for letting these companies box us in. But really — what’s the alternative? Where’s the paid Instagram clone that has the same network effect as the free one does? This is not an easy problem to solve.

Related post from the Elezea archive: Everything for free, always: how Facebook ads show us the sad state of the Internet.

There’s quite a fight going on in the comments of Elliot Jay Stocks’s A conversation with Erik Spiekermann. If you’re able to wade through the mudslinging you’ll find some good points in there, like this paragraph by Erik himself:

Design is first and foremost an intellectual activity which has nothing to do with what medium you work in. It is about looking at a problem, understanding it, translating it into visuals, actions, and messages. That is solving the problem, whatever medium the solution may end up in.

The worst work is done by designers who have decided on a medium before they even know the problem that has to be solved. Just like a print designer (and I do not make that distinction myself) should not immediately think brochure or poster, an interaction designer should also be able to think about other media besides websites or apps. Otherwise you end up behaving like the infamous hammer: every problem looks like a nail.

This relates to a point I made earlier that we shouldn’t let technology or devices (what Erik calls “the medium”) guide product decisions. The problem and the use cases should guide those decisions.

Des Traynor shares some insights on how he works with startups in Asking Questions beats Giving Advice:

The first question I ask (though sometimes I just ask myself) is an easy one: is this viable, feasible, and desirable? The answer has to be yes on all three counts—no two are enough. In fact, pick any two, and you’ll think of a start up that failed because they missed the third.

This approach shares parallels to the “problem frame diagram” approach I discuss in Usable yet Useless: Why Every Business Needs Product Discovery. The goal with that approach is to identify the user needs and business goals of the product, as well as the core competencies of the organisation.

Des goes on to describe some of the key things you have to think about before launching a product. If you do Product Management on the web, his post is highly recommended.