Why the Most Forward-Thinking Product Teams Work Backwards

Working backwards is all about starting with the desired end result in mind and then figuring out how to get there. Although everyone should already do this, there are plenty of times when this isn’t the case.

The key to working backwards is crystalizing where you want to end up. This means diving into the details of what the desired end result should be (more sales, happier customers, easier workflows, etc.), what the product must be capable of to achieve those goals, and what success would look like.

.. Starting with a press release

Made famous by Amazon, the working backwards strategy is a favorite among many product teams and thought leaders. A press release is usually the very last step in the product development and launch process. It tells the world: “Here I am, this is what I can do, and this is why you should care.”

To be effective, the author must step back from the technobabble trap and communicate in terms that resonate with the target customer.

“One important element of the press release is that it is written in so-called ‘Oprah-speak’. Or in other words, a way that is easy to understand,” says Nikki Gilliard of Econsultancy. “This essentially allows Amazon to cut through tech-jargon and any descriptions that would only confuse the customer, in order to deliver a mainstream product.”

.. Conducting a pre-mortem

A post-mortem (or after-the-fact review of everything that went right or wrong during a project) is a common method for organizations to learn from previous mistakes and successes to perform even better the next time around. It’s a group affair where representatives from the entire organization chime in on what worked well and what went astray.

A pre-mortem essentially places that same group of stakeholders in a time machine and asks them to imagine everything that could happen before a single line of code is written or design is mocked up. The goal is anticipating and wargaming the situation, spotting all possible scenarios so the team has already anticipated potential stumbling blocks and land mines.

These sessions begin by brainstorming every possible calamity that could befall your product, from total market rejection to compromising user data to sluggish performance and inability to scale. It’s a chance to surface every fear and doubt lurking in people’s minds and determining which are more likely to actually occur.

“Once you’ve collectively established your highest risks, you can start thinking about ways to mitigate these risks. Realistically, you might not be able to stop all risks from happening,” says Marc Abraham of Settled. “In these scenarios, you can still figure out how to best reduce the impact of a risk happening and come up with a ‘plan B’.”

5 Ways Product Managers Can Reduce Scope Creep

You were planning to introduce one new feature for the next major release, but suddenly, somehow, your team finds itself working on seven features all at once—all while under the pressure of meeting the original release date. How did this happen? Simple: The process suffered a little bit of scope giant leap. Solution? That’s also simple: “Let’s just stop working on those extra six features that weren’t part of our original plan.”

But it never happens that way. That’s why it’s called scope creep.

1. Share your product roadmap (early, frequently, and with everyone involved).

When everyone on your cross-functional team can see this high-level view of your product’s plans, priorities, and the strategic thinking behind it all, they will be more likely to understand how a request for what might seem to be a small additional bit of functionality will, in reality, have to disrupt some other part of the product’s progress.

So the more often you refer to and share your product roadmap with your organization, the clearer it will be to everyone that your finite resources for this project can’t afford scope creep.

2. Determine exactly what will constitute scope creep on your plan.

But then there are subtler forms of scope creep. For example, “I know we agreed on doing basic platform support for our app’s first release—just to let users access it with iOS or Android—but maybe we should go for optimum support, and include Windows phones, a desktop version, etc.”

3. Build “scope monitoring” into your routine.

4. Discourage your developers from over-delivering.

We know: This sounds awful. But as a product manager, one thing you should always remember is that your developers will often care deeply about the work they’re doing and will want it to be perfect. And in an ideal world—a world without budgets, or deadlines, or customers eagerly waiting for a finished product they can buy—you’d want your dev team building to perfection.

Unfortunately, though, you are always going to be working against the clock (and the accounting team), so you’ll need your developers to stop short of perfection and do the greatest work they can in the time they have allotted to them.

5. Make it easy to suggest and track great ideas for later.
One final suggestion for avoiding scope creep is to encourage your cross-functional team to contribute their product ideas and requests, and to make it as easy as you can for them to do so.

.. Then make a practice of periodically reviewing these ideas with your team, vetting and scoring them according to your key metrics, and, when it makes sense, updating your product roadmap to accommodate strategically viable items.

Ask HN: Move to product management at 35?

35 is a great age for a PM, especially since PM’s often start elsewhere — maturity is a plus here. I’d say there are 3 main ways into it — as an engineer, who starts to do PM-type stuff on a team where there’s no PM. As a designer, who starts to do PM-type stuff on a team where there’s no PM. Or as an MBA who has a good sense for engineering and design. Certifications generally don’t mean anything — communication and leadership skills, good judgment, experience and a proven track record are what matter. But all those things can be demonstrated in previous non-PM roles, in order to make the initial switch.

Also, if you want to be a PM then you’d better enjoy meetings, slides, people, and communicating & convincing all day long, day-in day-out. If those make you say an enthusiastic “yes that’s me!” then jump right in. If not… you’re gonna have a bad time…