Should PMs report the sales team on the progress of dev items? Before I joined the team, my module had not been improved due to concentration on other high priority projects for a few years, and now the sales team wants me to report on our progress frequently. Please respond whether you would be open to such an expectation in your organization if you are a PM who is passionate about implementing a cool feature in your product or module in a B2B setting and getting a competitive edge over the competition.
Working on more than 60 large and little enhancements that will deploy before EOY keeps me quite busy right now. A client’s comments and desire to work with us to build another capability (feature) may cause the plans to change within a week. Not to mention other feedback sources that may delay a planned functionality. While I want to act morally, I also don’t want to hand over the entire roadmap to a few teams. Please discuss your methods for informing sprint backlog members of plan changes. B2C PMs please feel free to comment but I felt the customer profile is very different for B2B software companies and so didn’t ask. Hearing from all PMs’ perspectives won’t do any harm.
I’m also curious as to how a product manager chooses to spend time creating a feature for a possible client when there isn’t a contract in place, and I have 200 customer requests in my module’s queue that I can take care of.
I challenge all of you lurkers out there who only skim these threads and never post to speak up now, before you watch me adopt wrong strategies here
Reporting the status of development items to the sales team is a common practice in many B2B software companies. It helps to align the sales team’s expectations with the development team’s priorities and ensure that the development team is delivering the features that the sales team needs to meet its goals.
However, it is important to consider the workload and priorities of the development team when reporting to the sales team. Regular reporting should not distract the development team from its primary focus on delivering high-quality features and enhancements.
Ultimately, the decision of whether or not PMs should report to the sales team on the status of dev items depends on the specific context and the needs of the company. It is important to have open and honest communication between the development and sales teams to ensure that both teams are aligned and working towards a common goal.
It is not possible to determine the team that weighs the heaviest in backlog grooming without additional information. The weight of a team in backlog grooming can depend on various factors such as the size of the team, the tasks assigned to the team, and the team’s priorities and goals.
Wonderful observation @DanCoelho. I would like to add my two cents here.
Effective communication of changes in the sprint backlog is crucial to ensure that all stakeholders are aware of the current status and priorities of the project. Here are some strategies that can be used to communicate changes in the sprint backlog in a B2B software environment:
Clear and frequent updates: Provide regular updates to stakeholders on the status of the project, including any changes to the sprint backlog. This helps to keep everyone informed and aligned.
Prioritization framework: Establish a clear framework for prioritizing features and enhancements based on customer feedback, market demand, and other factors. This helps to ensure that changes to the sprint backlog are made in a transparent and objective manner.
Stakeholder engagement: Engage stakeholders in the planning and prioritization process. This can help to build consensus and ensure that everyone is aware of the reasoning behind changes to the sprint backlog.
Impact analysis: Assess the impact of changes to the sprint backlog on the overall project timeline and resources. This helps to ensure that changes are made in a way that minimizes disruption to the development team and other stakeholders.
Transparent documentation: Document changes to the sprint backlog in a clear and accessible manner. This helps to ensure that everyone is aware of the current status and priorities of the project.
By following these strategies, you can communicate changes to the sprint backlog in a transparent and effective manner, while still maintaining control over the overall roadmap.
This is a typical but often extremely challenging circumstance for a PM. In a sales-driven organization where I previously worked, any innovation we proposed—no matter how thoroughly we verified it with customers—was shot down in favor of tactical upgrades to already-existing capabilities that would help retain existing clients.
Between short-term and long-term growth is where there is conflict. If you solely concentrate on tactical improvements, you will lag behind the market and become irrelevant in five to ten years. However, there are tactical enhancements that will drive retention. However, if you focus primarily on long-term innovation, business can run into cash flow problems.
We rarely get along well with sales teams since they are typically very short-term oriented. I spend a lot of time talking to the sales team and picking their brains for information, but I also have to keep the mindset that I can’t do everything.
I’m not clear how you are striking a balance between the trade-offs of:
Long-term (strategic) versus short-term (tactical) efforts
Features having a wider appeal vs those for particular clients (such as those where there isn’t a contract in place).
You seem to be trying everything, which typically doesn’t work. Building software requires a lot of time. Ten times longer than the business anticipates and twice as long as the developers expect.
Therefore, the sales team have given you $10 and are asking you to come back with ten large, gourmet pizzas and several bottles of fancy champagne. When you return with a few frozen pizzas, you’ll realize why they’re upset.
I’d want to ask you two questions:
Are your engineering teams sure they can fulfil all of your promises? How does this compare to what they have previously produced?
Do you prioritize closing a few deals, over achieving product-market fit? Will this strategy actually provide a superior value proposition than that of your rivals?
Deciding whether to invest time in developing a feature for a potential client when there is no contract in place requires careful consideration of several factors:
Market demand
Resource availability
Competitor landscape
Customer feedback
Risk assessment
Ultimately, the decision of whether to invest time in developing a feature for a potential client when there is no contract in place requires a balance of all these factors, as well as a clear understanding of the company’s goals and priorities. It is important to involve the development team in the decision-making process and to consider the potential impact on the development backlog.
Coming from an engineering background, I can reply to this. In general, it is important for engineering teams to be confident in their ability to fulfill promises before making them. To assess their ability to fulfill promises, engineering teams should consider several factors, such as, past performance, resource availability, technical feasibility, risk assessment. By considering these factors, the engineering team can make an informed assessment of their ability to fulfill promises and adjust their commitments accordingly. This helps to ensure that they are delivering on their promises in a way that meets the expectations of stakeholders and supports the overall success of the project.
Optimizing to win a few deals at the expense of product-market fit can be a risky strategy. While it may deliver short-term gains, it may not be sustainable in the long run if the product is not well-suited to the market.
A stronger value proposition than competitors is typically achieved by understanding and meeting the needs of the target market. This requires a deep understanding of the market, the target customers, and their pain points. By focusing on product-market fit, companies can create products that meet the needs of their target market and provide a compelling value proposition that sets them apart from their competitors.
In contrast, if a company focuses on winning a few deals at the expense of product-market fit, they may miss the opportunity to create a product that truly resonates with their target market. This could result in a product that is less differentiated and less valuable, and may struggle to compete in the long run.
In conclusion, while winning a few deals may deliver short-term gains, a focus on product-market fit is more likely to deliver a stronger value proposition in the long run and help the company achieve sustainable success.
Very beautifully outlined @EvaRichardson. 100% agree with you.
In order to acquire buy-in for the longer-term strategic stuff, I would also add that this article offers some useful talking points that can be leveraged to influence the larger organization (particularly senior leadership).
A 60/20/20 split of strategic, tactical, and technical work is what I encourage/enforce when my teams are concentrating too much on one or the other. The approaches I’ve discovered to be effective are:
Have a pressure release period of purely tactical work (sometimes rewarded/with bounties tied to particular outputs) when a team is spending most or all of their time on strategic outcomes;
or implementing a “week on/week off” or “sprint on/sprint off” timetable so they spend one period focused on strategic goals and the next on tactical and technical improvements, if they are stuck doing tactical work that isn’t actually beneficial.
To answer your question I am currently focusing on customer items as well as long-term innovation items so I have a good mix going there.
I would not promise a feature to the sales team without having a clarity from the engineering team that it is feasible. What could happen is that we end up tweaking the feature to make it work when the dev work starts.
I’ve had a long career in sales and so I’m always open to prioritizing features for potential clients as well.
Gotcha. My questions were more for you to reflect on rather than for me to criticise. A healthy relationship between PM and sales can make both teams more effective (I have that where I work).
It sounds like you are considering the trade-offs and being careful. I always find that dev work is at least 2x what is initially expected on legacy software (and that’s when the due diligence is done).
But I do agree that features should be prioritized for specific customers, so long the use case is valid more broadly.
Could you please elaborate on your position? You say, “I want passionate PMs here,” which sounds like a role for a group PM or director.
When you state you will deploy “60 significant and little enhancements before EOY,” it seems more like a feature factory than a strategic plan. How are you getting client feedback and interaction if you already have 60 items? Where can innovation take place?
Our organisation employs a high level roadmap with “now,” “next,” and “later” that anyone in the organisation may evaluate. In order for those same departments to see new products and ask questions, we also have a monthly Product display.
We have a strong leadership group, and I believe that they are in it to win the long game rather than the short game.
@Pankaj-Jain, every month, I deal with roughly 5 to 7 client calls. The majority of the interactions are with the C levels of our clients, analysts, and IS teams. I wish there was more end-user contact than there is. But we receive a ton of comments. As I have indicated, I have a ton of improvements planned for our current module, which I spent 15 months creating. Thanks for your suggestions. Since you provided insight into the actual procedure, I felt your advice to be the most helpful so far.
The pressure between long-term and short-term gain has always been there. Even in B2C companies, there have been a few occasions when I’ve had to push items into my backlog for delivery because a senior manager or director was convinced of the value of an idea or because they admired something so much that we presented it to them as a hypothetical scenario for their next marketing campaign.
Especially when you don’t have the full breadth of project/program support.
In B2B I’m client facing and have had clients try to demand in depth details. And tons of presentation. What I did was simple ProjectM spreadsheets that I could make client facing. So when a client asks about backlog. It’s as simple as sending a black and white spreadsheet with dates and basic details. That’s the simple answer.
But the way to build your career is make an event out of it. Organize your dev team in terms of releases and not features. Then put together a release deck. And present in an hour long meeting.
Two things
speak to sales people like a salesman. They don’t care about details, they just want showmanship and the appearance of awareness. Show them what we have and spend 15 min on what they can sell in the future.
Sales sometimes hates these meetings. Hour long sales pitch is annoying as fuck to a sales rep. They’ll stop coming and stop asking soon enough.
BUT…
What I have done is communicate to my boss I’m not a client facing talent and send some honest emails. “I don’t have time today. I can maybe have this next week?”
For the upcoming six months, we have a roadmap. It is quite helpful for communicating expectations. Salespeople can offer ideas, and the majority of them will be listed on the future board’s low priority bets.
Only commit to features after you have a strategy and launch schedule in place.
In a perfect world, you would already have a PMM process in place to train the sales team and sell the impending product additions.
Find a way to collaborate with the marketing and sales teams. Find a way to make them feel like a team. Sales and product are not the issue. Build relationships, decide on your shared objectives, then collaborate with them to achieve them.
Your strongest working relationship as a B2B PM should be with the Sales group. Their goals are also your goals, so you need to earn their trust so that you can sit at the table with them while they brainstorm ways to accomplish their objectives.
