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?
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.
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.
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.