By Saeed Khan
I sometimes get asked by clients to recommend “best practices” for Product Management teams, or by companies that are embarking on implementing formal Product Management programs.
Sometimes, they have a group called Product Management, but those people are mostly feeding requirements to the Engineering teams for releases and overseeing the development process. They are acting more like Project Managers than Product Managers. Given the varied situations, I have trouble answering the “Best Practices” question with small, easy to implement suggestions.
What worked “there” may not work here
Often people want to know what worked well at other successful companies because, there is an assumption that, it might work well for them. Given the lack of any other information, this is an understandable position to take. But what worked at Spotify or Shopify or Stackify or at that company’s competitors etc. will not necessarily work at the company looking for answers.
Product processes are far more cross-functional than other departments. They are also tied to and must change with the focus and maturity of that company. Whether you’re a software company or a consumer goods manufacturer, how you operate your product organization changes drastically with size, scale and maturity. It has to be that way. There’s no one size fits all solution when it comes to operating a growing or scaling business.
Are there really “Best Practices”?
Now, I have to say that I’m not a fan of the term “Best Practices”. I know what people are asking for when they use that term. But the term and the question (“What are some best practices you’d recommend?”) have implications that are not healthy in my opinion.
1. The term “Best Practice” implies that there is nothing better. They’re not asking about “good practices” or “better practices”, but “BEST practices”. And we know that is never the case; practices change. A “best practice” from a few years ago may not be a “best practice” today.
2. A “best practice” is only good if it’s applicable to your situation and your objectives. The question implies that there are standard things that are broadly applicable to all situations, regardless of context or need.
3, When a company asks up front about “Best Practices”, it tells me that they are looking for a quick-fix and probably don’t understand the scope or complexity of implementing the real changes that are needed. “Best Practices” are solutions; the end point. The initial focus need to be on problems; the starting point.
I’m not trying to be pedantic here. I get that “best practice” doesn’t literally mean the best (with nothing better). It may mean “standard” or “recommended” or “suggested” or “preferred” practice. But I believe that the words we use are important and can have different meaning and context to different people. Language is a tool, and we should wield it well, so that we can maximize the outcomes we’re looking for.
How to decompose the problem
When asked the question about “Best Practices”, my first response is:
What are the objectives or goals you
are looking to achieve?
This is important and yet often people haven’t thought through their objectives clearly, or can’t articulate them easily. Yes, they want to improve and get better but they haven’t thought things through to the point where clear objectives have been set. Let’s understand where they want to get to, before we try to give advice on how.
My next question (regardless of whether they can answer the first question or not) is:
Tell me about your current situation.
What’s working and what’s not working?
This is definitely easier for people to answer and helps me understand how much they’ve thought through where they are. The answers also help me dig down deeper into some of the challenges they may be facing or some areas that they may not have thought through deeply enough. We can also use this as a basis for clarifying some of the objectives they may not have thought about.
Always start with the problem
My view is simple. If you know where you’re starting from, and you know where you want to go, I can help provide some guidance — maybe even “Best Practices” — on how to get there. The key for the company to understand is what problems they are looking to solve, and identify priority and dependency.
i.e. what problems are more important than others, and are there dependencies or impediments that must be accounted for or addressed before the high-priority problems can be solved.
Sometimes, the problems may be clear, but the path to address them includes organizational and cultural barriers. If that is the case, then it’s necessary to focus on those barriers BEFORE any meaningful change can happen. For example, you can’t solve a process or skills problem if you don’t have a clear understanding of roles and responsibilities.
Even if you think you know what your problems are, I’m almost certain there are other issues you are not aware of that you’ll need to deal with. Having worked with a number of companies in this area, it’s a certainty that there are latent or (as of yet) unarticulated problems that need to be brought to the surface and addressed.
It’s almost never one problem
As an example, one question that gets asked quite often is:
We are not great at hitting our release dates.
We tend to miss them a lot, often by quite a lot.
What do you recommend we do to address that?
Now aside from repeating the “what are your objectives?” and “what’s working/not working?” questions, the reality here is that there are probably many factors that are causing the missed release dates. They could be issues in any or many of the following:
- requirements research and understanding of the problems
- problem analysis and decomposition
- estimating the work to be done
- scope changes during the development
- team skills (including technical knowledge) to complete the work
- organization or team dynamics during the development process
- management support (or lack thereof) particularly related to change management
- end-user involvement during the course of design and development
- or possibly other factors.
These are all high-level categories of where issues may lie. So, what’s the “best practice” here?
Spend time and understand the problems. Listen to your people. Let them speak in a safe, supportive and non-judgemental environment. Or if that’s not an option, bring in an external consultant to talk to them and share the feedback (anonymously).
Look for the common issues and patterns. There may be many problems, some directly contributing to the missed release dates, others contributing indirectly.
Don’t look for simple (simplistic) or quick solutions. The problems are not simple and didn’t manifest themselves quickly either.
It’s only when you can understand the problems in their fullest, can you define and execute a solution to match.
If your understanding of the problems
is superficial, then your solutions will
be superficial as well.
OK. Give me something for having read this far
So, having waxed on and on about “best practices”, it would be disingenuous of me to not to provide some kind of guidance to companies who are facing product challenges.
The following are not “Best Practices”, but simply (Highly) “Recommended Practices”. And on a certain level, they are simply table-stakes practices to follow for any product organization to minimize avoidable mistakes.
I’ve seen them work in a number of companies, and yet a lot of companies still don’t have some or all of these in place.
1. Have clear, well defined and achievable INTERNAL job definitions for your product team members.
I’ve encountered many companies that DON’T have formal job definitions. Yes, they have the “superhero” job description they posted online to hire people, but internally, there isn’t a clear definition of exactly what those people (e.g. product managers) are, and equally importantly, are not responsible for. This is important because if a company doesn’t define what product managers are ACTUALLY responsible for, then how will they be measured? How will they succeed? How will you know they have succeeded?
2. Understand that Product Management is a cross-functional leadership role.
Product Management acts as an accelerator for the business, bringing alignment across teams/departments in the organization. Its primarily role is NOT to spend time with Engineering, attending standup meetings, grooming backlogs and planning releases etc. Align product management goals with business goals and outcomes that need to be met. This will help align their work with the goals of the company overall.
3. Have well-defined product processes
This is a doozy and blog-post worthy on it’s own.
Most product processes in companies are ill-defined, if defined at all.
Q: How is customer research done?
A: Well we talk to customers and get requirements
Q: How is strategy defined?
A: Strategy? We’re not very good at that.
Q: What about portfolio management across your different products?
A: Ummm….yeah…we don’t really do that at all.
When I asked people in a workshop what their best product process was, one person said:
“We just get stuff done. We don’t have process.”
This is not good, but is also NOT a unique situation.
In another workshop, I asked people which of their product processes is the most well executed. The most common answer was “the Agile process”. And why was that? Because someone else (Engineering most likely) had taken the initiative to define and implement it!!
Why aren’t product teams taking the same initiative to implement their own processes in structured, measurable ways?
4. Have regular operational level cross-functional meetings led by product management
I can’t tell you how many times I’ve seen companies (even small ones) where, the following happened:
- the sales team doesn’t know what the product team is doing.
- the marketing team is creating product marketing plans without any coordination from product.
- the services/support people don’t have the information they need on new product rollout to do their jobs effectively.
Eliminating unnecessary cross-team friction is one of the most valuable (and easiest) things a company can do. It’s simply an act of deliberate and directed communication.
5. Have clear (measurable) product objectives and strategy, and communicate that widely throughout the company.
I’ve found this to be far less common than I would have expected. Often I’ve found that Product Managers themselves (let alone other groups) ) are not clear on the top-level objectives of their product, nor have much insight into the current state of revenue, profitability, growth etc. of their products. This is a symptom of larger problems that may exist within the product org.
6. DON’T hire a junior (albeit smart, determined & eager) person as your first product management hire.
There’s a whole series of blog posts that could be written on this, but I’ll keep it short. 🙂
This is a common pattern that I’ve seen in many startups. It hasn’t changed much over the years.
A startup founder (e.g. CEO, CTO, VP Eng etc.) needs help on the product side so they can focus more on other issues. A smart and ambitious internal person, from services, sales engineering, support etc. who “knows the product well and can talk to customers” is moved over to work in that new product role.
And while “knowing the product” and “being able to talk to customers” are good traits, they don’t even begin to encompass what a seasoned product manager (which is what the company needs at this point) would bring to the table.
Remember, for a startup, product success IS company success.
I’m talking about leadership, market savvy, analytic skills, negotiation skills, ability to manage up, understanding product processes like customer research, product strategy, roadmapping, working cross-functionally, overseeing go-to-market, internal stakeholder management etc.
Product Management is complex. Hiring a junior person as the first product manager solves a short-term tactical problem, but creates a gap because they don’t have, and may have a difficult time learning key product management skills that could accelerate product goals and objectives.
Remember, for a startup, product success IS company success. Why would you give such an important job to someone who has no background in Product Management?
I’ll stop there. I’d love to hear your thoughts on the topic of “best practices”. Do you agree or not with my view? Are there recommendations you’d make to companies on practices they should follow. If you’d like help in implementing ANY product practices, feel free to contact me.
Saeed
Saeed Khan is a founder of Transformation Labs and has worked for over 20 years in high-technology companies building and managing market leading products. He speaks regularly at industry events on the topic of product management and product leadership. You can contact him via Twitter @saeedwkhan or via the Contact Us page.
You must be logged in to post a comment.