We’re all familiar with the term, ‘passing the buck’ and how people evade or reassign responsibility to somewhere or someone else. Senior execs do it to product teams all the time. 

I’ve seen it happen to many product people in different ways over the years.  Perhaps you can spot some of the patterns below in your own organization and take action before they have an impact on your work.

Product management always takes the hit

You see it in companies where the bosses set expectations like unrealistic deadlines and then pressure the product team to stick to them. The team then has to struggle to get things out on time, even though it wasn’t their call in the first place.

Product teams could pass the buck to the development team – after all, they’re the ones who build and come up with the estimates that always seem to slip. But PMs always seem to take the hit for everyone else – and I think proudly so – I wouldn’t want to be advocating for a role that was known for throwing its teammates under the bus. Rather, PMs are known for defending the time of their developers (and designers), helping to get them breathing room and much-needed air cover. 

On the flip side, however, product managers often don’t get the same consideration from the rest of their organization, with the most notable offenders being sales teams and the executive team.

Sales teams may well ask for features to be built, rather than selling what they have. Saying they can’t sell the product until X feature is delivered puts all the pressure on the product team – but the sales team should take responsibility and learn to sell or reposition what they have. It’s easier for salespeople to expect the product team to add what they feel is missing. (And don’t get me started on the salespeople who sell things that don’t exist and dictate the roadmap!)

Executives with a badly formed business plan or model put the product team in a difficult position. A classic example is the agency trap, where the company (usually for short-term cash gains) accepts custom project/client work, while also expecting the product to develop at speed. But the product team only has so much time, and can’t do client project work and product discovery and development work at the same time, especially if the client work leads to a stream of deadlines to hit. And it’s not the product team’s decision or fault that they’ve ended up in a delivery-focused way of working. It’s been foisted on them by poor decisions at the executive level.

Unreasonable reliance on the product team

To be clear, the management team is responsible for creating a viable business and workable company strategy. But sometimes they over-rely on the product team to create something that doesn’t yet exist, in timeframes that they can’t know are reasonable (let’s be real: you and the dev team are still working out the scope of this thing, never mind how long it will be before you’re able to deliver). By doing this, management absolves itself of the responsibility of creating and maintaining a viable business, brushing it off as the product team’s problem with no consideration of whether it’s achievable. I’ve seen some teams given ridiculously tall orders.

A company strategy should encompass a realistic product strategy (plus realistic marketing strategies, tech strategies, and so on). It’s not a good strategy if it relies on miracle workers to make it happen or if it’s dogged by insurmountable problems.  The execs shouldn’t just ‘pass the buck’ on their bad decisions or bad planning to their product team and hope that the team figures it out. 

How do you stop it?

The product team must call out this passing the buck when they see it. To be able to do this product people must understand the wider company strategy and where the product strategy fits in it – it’s one of the most valuable things a product person can do. 

They should also understand who’s had a say in product strategy and where some of its assumptions came from. Was the strategy handed to the product team, or did they play an active role in defining how they could help the company reach its goals? 

If there’s a sense that others are ‘passing the buck’ to the product team, then call it out and set boundaries. If you don’t, then the product team risks having more work pushed at them, setting them up for failure further down the line. For example, if you keep agreeing to custom client work, to the detriment of discovery work, you set a precedent that you will always accept project work…  and the core product will never progress and the company won’t move towards its ultimate goals. 

Calling it out helps management and other team members to see the broken parts, like missing resources or misdirected efforts, so that they can help to correct them.

The post How Passing the Buck Sets a Product Team Up to Fail appeared first on ProdPad.

However, there is a danger in creating silos in product development and launch. We have to work out how to ease the transition from inception to real world usage, through every stage, in a way that reduces confusion along the way. It’s natural to believe this requires good project management, and well-defined handover stages, but there’s a better way. You’re more likely to succeed if you work as a collaborative product team including more than just traditional product team roles.

What should the product team structure look like?

We’ve all seen the chaos that can result from a lack of understanding when specifications are handed off from one team to another. There’s an element of “throw it over the wall” that means one team (product management) is finished and the next team (product development) can start.

We see similar issues when development is done and testing/QA starts, and then again when the success and operations teams have to work out how to deliver the new functionality. The problems stem from different functions having different questions about what needs to be done, and a lack of context from other teams. 

Let’s think about an example about the product team roles that might be needed. If we’re building a new search function, each team will have different questions.

• Product Management will spend time on defining the problem that will be solved. Is the purpose to help with discoverability? If so, what value will that provide to the user, and how will building this feature contribute towards the product team’s OKRs?
• Product Design/UX will want to know who’s using it, and will work with Product to create a user experience that is easy, intuitive and achieves the desired outcome.
• Product Development will want to understand exactly how the search needs to work in every possible scenario. They’ll need to understand every ‘state’ the UI could be in, the transitions, and any user workflows for interacting with the search bar. They might also want to understand the expected output of the search – is it fuzzy, exact text match or more abstract?
• QA will want to understand similar information to Development, but with more of a focus on what could go wrong. What will real world usage look like? How could the user encounter problems and how might they be overcome? Does it perform well under pressure or with high volumes of data?
• Sales & marketing will want to know why people will use this feature, whether there are any pricing implications, what the benefits are, and how they can tell the story of the new feature
• Success will be thinking about the search in real life, similar to QA, but they’ll want to anticipate what help will be required by the end user. Will they need any training? Are there changes needed to the documentation? How will this change affect existing users vs new users? 
• Operations will have concerns around how services are delivered and paid for. What will this mean for billing or finance? Will more resources be needed in any way? Does the change affect the way contracts are drawn up?

What is the key to a great Product Team? Collaboration.

The key to the product team’s success is collaboration. When we plan and define a new feature, we need to work with multiple teams to ensure that everyone has a voice. Don’t forget, as a product manager, your role isn’t necessarily to have all the answers, but to ask the right questions. 

Take the time to define the problem being solved. Once you’ve nailed that, you can start asking questions early on.

When leading the product team, a great product manager will ask the Design team to think about how they might design the user experience. They’ll ask the Development team what information they need in order to build the proposed solution. It’s important to have a chat with QA to see what they think might cause problems for the user in real life – get ahead of those problems before they become a surprise. 

Something that’s often overlooked is the need to discuss with the customer-facing folks what solving the problem means for their market, or their customers – how valuable could it be? Could you consider charging more for your product if you solved this problem? How would you position the solution, and what does it mean for your competitive position. Speak to finance and legal about the potential for changes in forecasting, pricing and contracts so they know what’s ahead.

Having these discussions from early in the product process will help to ensure that

• Everyone knows what’s coming down the development pipeline
• Each team can get ready for what lies ahead
• Risk is lowered – you’re less likely to have those last minute panics and changes
• Launch is smoother

The specifications need to answer any questions which will crop up during the execution/delivery of an idea, regardless of who’s asking the question. Gone are the days of writing up functional and technical specs and thinking you’re done – we need to think about launch readiness and ongoing operations too! 

How does ProdPad help?

Thankfully, ProdPad can help to ensure that the product team roles include representation from every part of your organization, regardless of their role. With unlimited free reviewer licenses, you can open up the product process to everyone to ensure there is visibility into the product roadmap. Discussions, commenting and collaboration features throughout the app means everyone is able to decide what they’re interested in and set their own noise levels.

ProdPad’s integrations with Slack and email mean that conversations can start, continue and reach a conclusion in the most convenient place for everyone involved. Not only that, you’ll get traceability and have a single source of truth for discussions and decisions made along the way – no more going back through old notes to work out who said what.

If you’re about to kick off a new piece of work, have a look at how ProdPad can help you get the best results in the most collaborative way. Get started with a ProdPad trial today!

The post What is a Product Team? appeared first on ProdPad.

Good question

1. An effective product team makes product discussions accessible to everyone else at the company

One day, a deeply annoyed Elon Musk sent all of SpaceX a memo titled “Acronyms Suck.” It was an executive order to stop using acronyms in the workplace because it was hindering basic communication among employees. 

“Excessive use of made up acronyms is a significant impediment to communication and keeping communication good as we grow is incredibly important.

Individually, a few acronyms here and there may not seem so bad, but if a thousand people are making these up, over time the result will be a huge glossary that we have to issue to new employees. No one can actually remember all these acronyms and people don’t want to seem dumb in a meeting, so they just sit there in ignorance.”

He was right. When you start to speak in your own language, in team speak, others can’t meaningfully participate in the conversation. 

The product mindset requires everyone at the company to be able to discuss the product in terms everyone can understand.

A truly effective product team communicates with sales, support, marketing, development, QA, and so on, in a way that is meaningful to each of those teams.

We do two things to keep our product conversation open to everyone on the team:

1. We give everyone access to our product backlog. Everyone can drop in ideas, suggestions, and comment on existing ideas. (We review and respond on an ongoing basis.)
2. We don’t accept ideas without a short 1-2 sentence business case, a high-level argument for moving that idea forward. This filters out frivolous ideas. 

This process forces everyone to think about their suggestions in terms of business value rather than personal preferences:

• What problem are we trying to solve?
• What value would it provide if it were solved?

Essentially, if you want something done to the product, you have to defend it in terms everyone understands. If you’re suggesting something that doesn’t move the needle, then is it worth suggesting? Is it worth taking up several people’s time to work on?

These kinds of questions are now baked into our company culture.

2. Effective product teams use high-level product and business goals to drive their team-level work

Call them what you want – OKRs, KPIs, objectives – but effective product teams assign high-level product goals that everyone else can contribute to.

Any of these are tangible enough to work:

• Increase trial-to-paid conversions by 15%
• Reduce new user churn by 3%
• Increase trials to 500 per month

When we decided to increase our trial-to-paid conversions, each of us took off to complete our own set of tasks.

Our CPO went into our analytics to dig up user behavior during the trial period.

That told us which actions our most successful users were taking before they became paid customers.

Our Head of Growth designed an email drip that would convince new customers to take those actions right away.

Our Head of Customer Success created a set of masterclass videos to visually teach new users how to take those first actions.

Meanwhile, we got together as a team to redesign our entire onboarding experience.

The actual nature of the objectives will differ per product team, as they are usually tied to the product itself. (For SaaS metrics, get this cheat sheet from Chartmogul.)

But the principle remains the same – if you want to keep everyone aligned around your product, set goals that are tightly wrapped around your product.

3. Effective teams give company-wide access to customer feedback and support tickets

Slack gets all my love for this one.

We’ve set up a Slack channel to send us incoming Zendesk tickets so that all of us are in on them.

In companies where customer support is considered a separate function, everyone else misses out on the stream of raw customer feedback, comments, and questions.

As far as I’m concerned, this is as good as gold.

Our Head of Customer Success also ropes all of us into doing customer support when she needs us. Rather than pinging us separately, asking how to answer, and answering the ticket herself), she assigns us the tickets that we’re better positioned to answer.

We also use our own Slack-ProdPad integration to send all our customer feedback into our backlog. Rather than make an informal comment over lunch like “X customer just told me she hates our new phased rollout,” we collect them in ProdPad.

Here, they become a formal part of our product process. So long as we put our notes back into ProdPad, they will be seen, and tagged, and they will be considered when the time comes to address that issue.

The alternative is that the customer feedback we field while we’re on the road meeting customers, at conferences, and so on just disappears into thin air.

4. Effective teams invest in making users feel badass

People use products that make them feel badass, and they invest time and energy in products that make them feel badass.

That’s developer evangelist Kathy Sierra’s message to product teams and companies: make your users feel awesome, badass, and good at what they do.

Sometimes, this means thinking beyond the product itself.

We take our cues from companies like Unbounce, a company whose marketing strategy is to create and give away the most useful digital marketing knowledge possible. Their resources are so well produced, thorough, and genuinely useful that they hardly qualify as marketing in the traditional sense. 

I see it as effectively a companion product to its landing page tool – a growing library of webinars, courses, e-books, and posts that help users become really confident marketers.

This collaboration of marketing and product, which don’t always cooperate as they should, is a clear victory for the company.

Where are customers struggling? What do they want to learn more about? What would make them more confident at work or in life?

There’s your sweet spot.

Similarly, our own marketing revolves around helping our users become better product managers.

For example, when we saw one of our blogs, How to Build a Product Roadmap Everyone Understands, start to attract significant traffic, we doubled down the topic. Now, our free, in-depth e-course on the same topic has become the go-to resource for building a simple and agile product roadmap.

Is it marketing? Is it customer success? Based on my experience, just say no to labels and do whatever makes your users feel smart and ready to take on the world.

5. Effective product teams put the final decision and/or veto power in the hands of a single product manager.  

Sure, there are risks to giving one person the power to decide what stays or goes but the alternative is death by committee – and it’s hard to recover from a culture like that.

Product decisions made by committee result in compromise, and compromise is how Windows 8 happened.

Leave the back-and-forth shuffling and the mealy-mouthed product decisions to a less imaginative product company. It takes a single bold product leader who has the power to insist to catapult products into first place. There is one caveat: before making that final call, Product Managers should ask their colleagues what they think. 

One of our customers Ajay Dawar, VP of Product Management & Design at Everstring, does this in a really interesting way.

First, he talks to the CEO and exec team about what they believe the product direction should be. Then, he poses the following question to each team leader:

“Over the next 90 days, what’s the most important thing for us to do?”

Based on those discussions, he curates a set of ideas from an otherwise long product backlog for them to stack rank. Stank ranking effectively forces his colleagues to assign their priorities a numbered list – no ties allowed.

A committee might be tempted to say: “Can we squeeze in both?” But he has the full support of the company to make the final decision.

Speaking of final decisions, the other caveat is this: No decision has to be final. Any good product team is always testing, learning, and iterating based on the results.

Every product decision should be subject to change.

The post Product Teams: What Highly Effective Ones Are Doing Differently appeared first on ProdPad.