Menu

“Marketing-driven development is bad,” and other misconceptions of product management

I like the reframing Sherif Mansour does in his talk Popular Misconceptions of the Product Craft. For example, here is his response to the common misconception that marketing-driven development is always bad:

As product managers we should always educate our teams on the value of great marketing, embrace the art of storytelling that infuses our marketing teams, and think about how we can bring that back to our teams. Whether you follow Amazon’s press release method, mock-up landing pages before starting a new feature, or do a box design exercise where you design the fictional in-store box for your new product, thinking about the Who, What, and Why of your product can help you build a better product for your customer.

Culture/market fit is more important than product/market fit

I really like the NOBL team’s focus on Culture/Market fit in their article The Only Thing More Important Than Product/Market Fit:

Find yourself a healthy market, yes. Then develop a culture that can deliver product/market fit. Your culture is what produces your products and services. You know you have culture/market fit when both talent and customers flock to your company for who you are, even above what you make. You know you have product/market fit when legions of customers buy your product.

Without culture/market fit, sustainable product/market fit (at any size, scale, or maturity) is impossible.

They go on to describe four competing flavors of organizational culture, each with unique traits and competitive strengths.

Users don’t want control, they want a better solution

Ian Bicking makes some very good points in his post “Users want control” is a shoulder shrug:

Control is what you need when you want something and it won’t happen on its own. But (usually) it’s not control you want, it’s just a means. So when we say users want control over X — their privacy, their security, their data, their history — we are first acknowledging that current systems act against users, but we aren’t proposing any real solution. We’re avoiding even talking about the problems.

I like the framing of the broad concept of “user control” in this very Jobs-to-be-Done way. It’s almost like a safe word to watch out for. Whenever we catch our colleagues (or ourselves!) arguing for giving users more control over something, we should immediately stop ourselves and try to uncover what deeper need the discussion about control might be obfuscating.

Why it’s not a good idea to define a fixed project scope

There are some decent day-to-day work tips in Sierra Newell’s 7 Project Management Principles Product Managers Can Learn From. There’s one principle I wanted to expand on, and that’s “Define the scope and stick to it”. First, from the post:

Product managers should set the scope of their products’ development as early in the process as possible. Learning how to say no to product requests is a valuable skill. But it is also a reactive method of keeping your product’s development on track. Instead, be proactive. Define your product’s scope from the beginning, and keep development within that scope.

I know that “define the scope and stick to it” is fairly common practice, but I don’t think it’s a good way to build product at all. First, that principle tends only to define one side of the spectrum — how not to add scope. It doesn’t, however, talk about the need to sometimes reduce scope. If you define a “fixed scope” and say you won’t go over it, but then things take longer than anticipated (as they are prone to do in software) and you have no mechanism to deal with it, you’re going to get yourself in trouble. Because at that point, you “committed” to a scope that won’t change, presumably saying “no” to a bunch of things, and still you’re “late” in delivery.

This is why I’m a firm proponent of “fixed time, flexible scope” projects. Under that principle, you don’t lock down the scope for forever and ever. You commit to an initial body of work, and an expected timeframe. Then, if something happens along the way — a developer gets pulled into an emergency, or something takes longer than expected — you have a mechanism to deal with it. Since you didn’t lock down the scope, you don’t have to choose between being “late” or the team working themselves to death. You can reduce the scope of your work to fit into the time you gave yourselves to do it in.

There’s another scenario under which I would go even further and advocate for “flexible time, flexible scope” projects. There are instances where increasing scope (and time) is the Right Thing To Do for a project. For instance, if the choice is between a hacky way of implementing a feature, and extending functionality properly with future-proofing in mind, which would add two weeks to a project, I believe it’s pretty much a no-brainer that you need to add the two weeks.

This is why I think fixing scope is a dangerous practice. There are too many unknowns, too many variables, and too many things can change along the way. We shouldn’t let our process get in the way of good product decisions.

How product managers can get better at their skill gaps

Marty Cagan posted another great installment in his series on how to be a good manager of product managers. In Coaching Tools — The Plan he describes the different ways he would encourage product managers to skill up in areas where they need to grow.

It’s hard to pick just one quote to post because the whole article is excellent, but these paragraphs on collaboration particularly stood out for me:

Modern product management is all about true collaboration between product, design and engineering. This begins with ensuring the product manager is knowledgeable about the real contribution of product design and engineering.

The PM does not need to be personally skilled in either design or engineering (most aren’t – although many PM’s think they’re great designers) but they do need to understand and appreciate their contributions to the point where they understand that what each of design and engineering brings to the table is just as essential as what the PM brings.

Product specifications: our template and process

My previous article on the dangerous rise of “crazy-busy” product managers generated quite a bit of feedback. One part of the article that was a bit of a throwaway, but became a focus of many of the questions I received, is on the way we have our team leads work on product specs. As a recap, here’s what I said:

The point is to think about areas where you do all the work or where you’re a bottleneck and you don’t need to be. In our case at Postmark, I frequently got overwhelmed with spec writing. So we changed that. The lead designer/developer on a project now writes the first draft of the spec (we have a really nice template), and the rest of the team (including me) comes in afterward to ask questions and polish to the doc. The added benefit? Those team leads now have a way better understanding of the work they’re about to do, and they also feel a strong sense of ownership.

I got questions about the template we use, as well as how team leads find the time to do that. So I wanted to give a little more context on that.

What template do you use?

There is no shortage of “product spec” templates out there, so the one we use isn’t particularly groundbreaking or new, but I like it for a couple of reasons.

First, we’re very serious about the “living document” nature of our template. We don’t fill out the whole thing up front, we host it in Dropbox Paper, and everyone on the team has full edit access. We truly work on it together.

Second, I’ve had over 10 years to iterate on this. So yes, there are many product spec templates like it, but this one is mine. I like the focus on defining the problem, the market, the risks, and the success metrics before anything else happens. I like the modular nature of it — just use what’s applicable to the project. And I like that it’s fairly short and focuses only on what’s needed.

You can view the template on Github. Feel free to send me feedback!

Where do your team leads find the time?

I guess saying that our designer/developer leads write the first draft of the spec raised some eyebrows. So let me address that. At Postmark we’re constantly evolving our development process. As of now, we usually plan for 10-week development cycles (which includes multiple smaller releases). This is followed by a 2-week “off-cycle”.

During the off-cycle we don’t take on any new projects. The team uses this time to polish anything they didn’t get to during the regular cycle, focus on some bugs they wanted to get to for a while, respond to customer feedback, etc. But we also use this time for planning. This is when we get together as a team to discuss the problems we want to solve in the next cycle, and work on planning together.

So the answer to the question “Where do your team leads find the time to write specs?” is simply: we give them time. Their “project” during the off-cycle is planning for the next cycle. Thinking through the problem, consulting colleagues, learning any new skills that would be helpful — this is all you are focused on during those two weeks.

This has worked really well for us, because we start every new development cycle with a good understanding of what we want to accomplish. Our teams are fully immersed in the process, and have full ownership of their solutions. And I feel much better too, because I was able to spend quality time on each plan, asking questions, guiding where needed, and making sure we keep our focus on the right things.


Of course this solution won’t work for everyone, so this isn’t really advice. Let’s call it “shared experience.” I’m not saying everyone should work this way. But I will say that it has made us much more productive and efficient.

Why it’s important to watch (and understand) your product churn

Shaun Juncal has a good overview of the importance of watching your churn numbers carefully in his post Churn: The Most Important Product Metric for SaaS. It’s especially important to figure out why people leave when they do:

But you can also learn something from that lost customer, namely why they left. Were they drawn to a competitor? Did the value your solution offered fade over time? Was a missing key feature causing them to bail out? Answering these questions can inform what should be done to retain your current stable of paying customers and attract new ones.

A simple churn number can’t tell you why someone leaves, so this is data that has to be collected qualitatively. But how? You don’t want to provide a negative user experience to customers on the way out, so putting a giant hurdle in front of them is not a good look. We solve this problem at Postmark by providing an optional text field on the page where you select your downgrade option:

I’m sure we would get more responses if we made this a required field, or turned it into a pop-up. But at what cost to negative perception would we do that? Following someone as they exit a store is creepy. Don’t be creepy.

How to build trust, and other advice for product manager soft skills

Claire Lew’s article on the 9 mistakes you don’t know you’re making as a new manager is written specifically for people managers, but I found a lot of good advice in there that relates to the product management role as well. For example, on how to build trust with a team:

However, in our survey of almost 600 people, we found that team-building activities were in fact rated as the least effective way to build trust. What was rated as most effective? Being vulnerable as a leader, sharing your intention, and following through on your commitment. In other words, trust isn’t about building rapport – it’s about you making clear why you’re doing something, and then acting on it.

I’ve found this to be 100% true — both in my dealings with my managers over the years, as well as building trust with different teams. This is not your usual “listicle” article — every tip in here is gold.

More

  1. 1
  2. ...
  3. 41
  4. 42
  5. 43
  6. 44
  7. 45
  8. ...
  9. 201