Don’t Waste Your Time on A Scrum Certification - Do This Instead To Be A True Product Leader

Don’t Waste Your Time on A Scrum Certification - Do This Instead To Be A True Product Leader

If you are an aspiring Product Manager or Owner - or already working in the industry - then you will see many job postings asking for some sort of Scrum certification.

Or you’ve seen other PM/POs on LinkedIn with a load of qualifications after their name e.g. “Henry Latham CSPO CSMII OMG CTC FYI CEC”.

From my personal experience as a product leader, as well as working with A LOT of aspiring product leaders within the Prod MBA, let me clear:

These are not only a waste of time, but create a dangerous misunderstanding of what product really is, as well as what your role is as a product manager.

For the sake of this article (and my sanity), I’m not going to delve into the misconceptions surrounding the role of Product Owner v. Product Manager. I have done so in a number of other articles (such as my article on Outcomes v. Output here).

In this short article, I will, instead, focus on why the Scrum training industry exists, the dangerous misconceptions that exist because of these training programmes & why they entirely miss the point about what product is really about.


What is Scrum? 

But first, what is Scrum? And why are we even talking about it? 

Scrum is, according to scrum.org, “not a methodology. Scrum implements the scientific method of empiricism. Scrum replaces a programmed algorithmic approach with a heuristic one, with respect for people and self-organization to deal with unpredictability and solving complex problems. “

The emphasis in theory is on a loose set of principles and frameworks for approaching product development. Specifically, working out what to build and how to build it in a continuous cycle.

In practice, however, the emphasis on “heuristic” - in short, the behaviour & thinking of the product teams that follow Scrum (whatever they interpret Scrum to be) - tends to be lost in the process.

Why?

  1. Unfortunately, humans have a tendency to try to simplify things in order to make sense of the world.

Therefore, where Scrum may - in theory - stress the need to be adaptive & not strictly follow methodology or framework, the methodologies generally /associated/ with Scrum (such as an organised product backlog, planning, estimation of tasks, 2-weekly sprints) tend to be what is most focused on.

Add to this another human tendency:

2. To only be able to focus on one thing effectively at once.

In my experience, this means a product team’s focus tends to look more at simple, tangible measurements of progress (number of story points or tasks that have been completed, in most cases), rather than intangible things like asking, “How do we know we are building the right thing?” Or “Are we questioning big strategic assumptions constantly? And are we incentivising ourselves - or being incentivised - to ask these big strategic assumptions?”


Why Can Scrum Undermine Your Success?

Well, firstly, it means product teams that have completed Scrum training, or work in organisations where Scrum rituals are highly valued, focus on efficiency at the expense of effectiveness:

They get good at building features quickly, but don’t stop to question whether they are building the right features (and using discovery work & customer insight to work out what the right features may be).

Secondly, this whole Scrum training industry exists that sells an idea of what your role in product is really about that is quite simply inaccurate.

I’ve heard all the arguments: “Well, they are just doing Scrum wrong," or "the training organisation is bad.” 

Well why are they not being critiqued for it? Why is there not an effective alternative to demonstrate what product is really about?

Instead, organisations like Scrum Alliance push the narrative that getting a qualification from them means that you are then ready to “do product”.

Yet anybody that has worked in product - or has completed one of these trainings - will tell you this is blatantly untrue. 

Product is not something that can be taught in theory.

It can only be learnt in practice.

Because it is not about rituals or methodologies or using the right framework. 

They help, sure. But they are not essential to success.

Instead, growth as a product leader comes from applying theory to practice.

Not reading about what product vision & strategy is, but, instead, crafting both in the real world with real potential customers & coming up against the obstacles & failure that any good product leader knows you will inevitably meet along the way.

Not reading about how to use customer insight to inform that strategy & a product roadmap, but actually speaking to customers & aggregating their data into insight and, in turn, into product ideas, in the real world.

Not reading about the difficulties of running a startup or leading a team through uncertainty, but actually doing so. Actually seeing yourself fail, picking yourself up again, trying out a new hypothesis, then iterating until you uncover success.


How To Become A True Product Leader

You can do more than you think to take charge of your product career.

If you find you work in a company that is only interested in you pushing features as quickly as possible - an environment we call a “Feature Factory” - then launch a new product in your free time.

If you find yourself a bit lost - or questioning your ability to run your product team effectively - then experiment! Read about the things that really matter - product vision, product strategy, using customer insights, motivating your team - then carve out 30mins per day to put these ideas into practice.

And if you find yourself lost with regard to where to start, then it’s worth looking into the Prod MBA, where, over a 6-week, part-time training programme, we get you to walk the hands-on, uncertain path of developing your own product from scratch - from idea, to offer-market fit & on towards product-market fit. You can try our free Mini MBA here.

Whatever you do, just remember:

Theory & ideas mean nothing. Only being able to put these into practice & experiencing what it is really like to run product does.

So optimise everything you do to make that happen.


James Ross

Head of Product at Autopilot | Autonomous Brand Operations

4 年

I saw this attached post on the Product School facebook group (took a screenshot without name to anonymise) and it made me think of your post here. Whilst there are good concepts and ideas within Scrum and other frameworks - I think that bringing context, alignment and clarity across departments (Eng, Sales, Marketing etc) is a crucial role to being a PM. We have to ensure a common understanding and language is part of that. If you start speaking this abstract language of story points and average velocity, as seen in this screenshot, I just dont see how that can be helpful overall. As a PM who hasnt worked with Scrum, Ive literally no idea what a fellow PM is talking about here - imagine what it feels like for your stakeholder in Sales. Its hard enough translating technical topics into your sales world and vice versa, bringing market research into the engineering scope, without adding more complexity. See also: unnecessary use of acronyms in companies, a problem Ive seen often and even good old Elon Musk seems to agree with: "Excessive use of made up acronyms is a significant impediment to conversation. No one can actually remember them and people don’t want to seem dumb in a meeting, so they just sit there in ignorance. This is particularly tough on new employees.”

  • 该图片无替代文字
Henry Latham

Built 8 startups. 6 failed. One hit $900k in 4 years, another $25k in 14 days. Follow to copy my process for building 12 startups in 12 months

4 年
回复

要查看或添加评论,请登录

社区洞察

其他会员也浏览了