I recently started working for a new company, and throughout my interviews, they were able to persuade me that they understand what product management is and that they practice it well.
But when I started working there, I saw that product managers weren’t actually conducting product management. Here are some additional findings I made and verified:
There are no data insights and customer feedback for the product. Customer feedbacks are premature and too early to be done, according to the head of IT.
Clients just provide the scope of work, and project managers break it down into user stories.
PMs track the number of hours that developers put in during a sprint. No narrative pointing. Overtime is the norm.
Typically, sprints are cancelled because the client has a higher priority, and the PM has no control over this. T-Debt is therefore at its highest point.
The Scrum Master, who doesn’t even understand how scrum works, tells everyone what needs to be done.
Lack of discovery and problem validation.
Any other signs or scenarios you’ve encountered? Please contribute.
Have you joined a consultancy where you create products for customers? If that’s the case, I doubt you’d be able to conduct any meaningful product management if you weren’t a part of the company; instead, you’d just be a project manager who delivered the product the client requested.
If your new company is a consultancy/agency as GrudenCarr2020 pointed out, I don’t think there will be much product management unless you’re developing an internal product. Is it a product company or a consultancy/agency?
@Nathanendicott, I cannot say it is a consultancy agency, since they have an actual application that they are selling. However, from there, they somehow became a consultancy.
Sounds like a company that relies more on consulting for custom professional services than it does on the features of its products to generate revenue. Basically, a vanity “product” from a closet consulting organization. Unquestionably not a product-first company. Would stay away from those places in the future.
There are several ways to evaluate a company’s culture in a product-based company, including:
Employee surveys: Surveying employees on their perceptions of the company culture can provide valuable insights into how well the culture is aligned with the company’s values and goals.
Observation: Observing how employees interact with each other, how they approach their work, and how they handle challenges can provide a good sense of the company culture.
Interviews: Interviewing employees, managers, and leaders can provide a more in-depth understanding of the company culture and identify any areas of improvement.
Analyzing company policies and procedures: Examining the company’s policies and procedures can provide insights into the company’s values and priorities, and how they are translated into action.
Examining the company’s external reputation: How is the company perceived by outsiders, such as customers, vendors, and industry peers?
Sorry to hear that, though. Inquiries you might make during interviews include:
What recent projects did you start? How did you make your choice?
What last feature did you remove? How did you make your choice?
What new information do you have about your clients? Your method of learning it
What distinguishes those who succeed here from those who fail? Give some examples.
In essence, you want them to provide particular examples of the decisions they’ve made regarding products. You can find more information on finding the right fit here.
No story points is not necessarily an issue. Actually the “inventor” of story points seems to regret it, and now recommends time-based estimates… (The rest seems awful)
Doesn’t sound like Product Management… Sounds kinda like a textbook Product Owner role, where you build a backlog based on client requirements and deliver small, measurable, testable items of work every Sprint (if it doesn’t get cancelled)
Other red flags I think would be:
Requirements provided with full solution or, even worse, by providing a link to your competitor and the stakeholder saying ‘I want this functionality’
Signs that your backlog is influenced by ego driven decisions rather than data or customer problems
People doing more than their job roles
Clients or stakeholders providing a deadline to you and the squad before you have had a chance to size or estimate effort.
Transformation in my place was, let’s not change anything because that would require management to decide something and they have no clue.
They use SAFe and as a PO I was supposed to contribute to the roadmap. After 1.5 years there was still no product roadmap. I had created several roadmaps for my part, all approved but not followed by the PM and we were tasked to build unimportant things. Of my 1.5 years there, we could count less than a month of really important work in 2020. I did that exercise with my senior dev guy. That was depressing.
PM could never provide a clear answer to what the customers wanted, and his only priority was looking good in front of his manager.
Man, that sucks and sounds similar to my situation at my last company. It was miserable for everyone to spin your wheels and get nowhere, all the while upper management thinks everything is progressing.
A thing I look out for as table stakes of good product practice is using burner landing pages or other types of smoke tests to validate and quantify user demand before prioritizing. Clarifying, all product teams SHOULD do this kind of validation testing with burner pages.
Another bad sign I have seen is tech-led decision making. Meaning, that the tech team is prioritizing items on the roadmap that they want done, like refactoring code, without buy in from the product manager. That can be a sign of severe dysfunction in the organization.
@HannahBorges, I’m probably mis-reading this but are you saying these validation techniques are bad practice (landing pages and smoke tests)? If so, what would be the recommended way?
Companies that DONT use those kinds of smoke tests to validate are missing a fundamental piece of validation testing and it’s a sign of bad culture when they don’t do those things.
I think this whole thread is gold mine. I am sorry for the bad experience the author had.
The whole conversation here and people feedbacks are really valuable and interesting. This helps me a ton.
My input to the topic:
A bad practice I saw at my company is out-dated product budgeting strategy which reassemble Waterfall. Basically, we want to be Agile, but we make 1 year roadmaps, budget the effort at the beginning and aim to execute on that. No room for changes during the year. No budget for new outstanding and customer valueble features or whatever. No flexibility at all. Any client feedback is used as an input for next year roadmap.
The client X is too big and defines backlog for a product Y. This creates such a tailor-made product for client X that it doesn’t fit the rest of the market.
This sounds like a classic example of what I call “Consultancy as a Product.”
What I mean by this is when a company has been selling their own app just long enough that they know their existing user base/clients but have become so disenfranchised from building the product that they’re adding features to the product directly based on the need of the client(s). Think “Feature Creep” but driven only on the notion that prioritization comes directly from how large the customer is demanding a new feature or just how loud they’re yelling from the other end of a conference call.
Hear me out:
Your Head of Technology is probably in the state that they fear requesting customer feedback would mean more projects to manage/implement. It may be easier to implement some digital adoption platform (Walkme/Pendo/Google Analytics) to begin understanding user behavior. But considering doing so would be a technical project, I’m assuming they won’t even bother.
This was the “major” red flag for me. I’m sure many of us in product management have run across this exact scenario, either as a one-off for a large client or as a never-ending flurry of projects. When the roadmap is 100% determined by your clients, you are fundamentally a consultancy firm for your own application/product.
I know others have pointed it out; however, story points aren’t the “end-all/be-all” of managing a sprint. Output is more important than story points, but each sprint should have a well-defined expected output. Scoping user stories and working with the development team will, in time, build out more reliable sprint planning/execution. As for overworked developers - you’re not going to get much creativity or “good” solutions.
“Consultancy” red flag #2 - Clients/Customers should not be able to cancel a sprint in such a hostile way. We’ve all been in the position where there’s a bug or feature that doesn’t work exactly that way a client wants it to work. If your company is out-right canceling the sprint and re-directing the attention on these things, there isn’t any genuine direction or purpose of a sprint (to the point that it sounds like a sprint only because it’s a “collection of work within a specific frame of time”). This will burn you out, sooner rather than later (along with the development team).
A lot of people using Scrummerfall or just Scrum (alone) haven’t a clue what a ScrumMaster is meant to be doing in their organization. With everything else you’ve outlined, I can’t say that I’m surprised by this point. The sprints are ad hoc, the customers determine the roadmap, and the organization doesn’t understand how to build out the product any further than it is right now. The ScrumMaster seems to be a byproduct and perpetrator of this system.
We reach the end of your list and … yeah, this is another red flag that points towards “consultancy” (note the quotations).
I agree that the organization you’re working for doesn’t seem to fully understand how to manage their product at any stage in the lifecycle. Development is in a perpetual cycle of building out features based on a single client’s demand. The Scrum/Scrummerfall process has broken down too many times due to the lack of direction. It does seem like this is a poor application or definition of a Product Manager role within the organization. It isn’t uncommon for a PM to function as the PO as well (especially in smaller companies). In this situation, it does seem as though you’re in a “Consultancy as a Product/Vendor” organization and the PM is strictly a project manager with more eyes on the “product.”
This is definitely a precautionary tale and it’s unfortunate that you’ve experienced all of these things within the span of a month. They may understand what product management consists of at its core but with the caveat that they decide to invoke that definition in a very ad hoc way. Or, perhaps, they had implemented a decent product management framework until the business dove and they started playing “keep the customer happy” to the point of becoming a consultancy firm for their own product.
