I came across this while listening to the wonderful podcast “The Product Podcast” which I highly recommend. The folks that put it on collaborated for months with top talent across multiple industries, from all over the world to create a manifesto of 10 principles for product people everywhere. I am so behind this type of mission and think the profession as a whole, benefits from defining a pretty ambiguous set of roles.
Ask “why” before “what,” use data and research to reveal the opportunity.
Derive goals from user problems and the broader team mission.
Frame the story starting with the problem, quantify it to show the opportunity, then arrive at the solution.
Set team goals and principles, then bring everyone together with written artifacts, frequent feedback, and communication.
Work backward from goals, align on prioritization frameworks to support decision making, and set clear boundaries based on resourcing realities.
Start by understanding the problem, bring the team together to deliver a resolution, do a retrospective to avoid the crisis again.
Find a role with problems you are passionate about solving, then build at least one core skill while delivering solutions.
Set your aspirations, ask for opportunities, set goals with managers or mentors, solicit feedback, and put in the work.
Begin with four pillars: goals, structure, alignment, and measurement, then adapt each to your context.
Create a cross-functional team to focus on specific problems and enlist diverse perspectives that represent your users and stakeholders.
I really appreciate the effort here, but I am having a really hard time liking this. I think one of the most important jobs for a PM is to communicate ideas clearly and concisely. The list feels like a mess to me, clunky and like it was written by committee (I realize it was but still), jargon filled and overly complex. Say what you will about the 20-year-old Agile Manifesto, but it was short and elegant and is still referenced 20 years later.
I’d love to hear other thoughts on this and be convinced I’m being too critical!
It seems crazy to me all of these smart high-level people worked together and then thought this was good. But, say what you will about the crude phrase, it does seem like it turned into a circle jerk trying make everyone happy. The word goal is mentioned in 5 of the 10. It’s like someone kept saying, well don’t forget about goals!! So, they just kept adding to in there.
@MarioRomero, Eh, I don’t think it’s good to throw out the baby with the bath water. Marty Cagan and his friends are spreading generally good things (even if I find some of them unrealistic) and they are deployed into orgs at the leadership level to help leadership establish a generally good product culture. That’s really valuable, because so many PMs in our industry are not given agency and are told to just be a Jira Jockey who takes orders from senior management. We need folks who can be deployed into leadership levels of companies and tell them to change their shitty practices.
My main problem with it is that it doesn’t read like a standard manifesto, which is generally things that can have no exceptions because they are guiding principles to how we do work. This list is more like a set of instructions for doing product better. The language is passive and instructional as opposed to direct statements of truth.
If you read the agile manifesto, it’s all about people relationships and getting to the end goal. It has nothing to do with the explicit act of development because it’s inclusive of all members of a team who builds the product.
For example, “derive goals from user problems” would be more effective as “Users are the source of truth and the reason your product exists.”
Feels like it’s in need of a v2 to me. I don’t disagree with what’s in there, but it’s too many words and too much to keep in my head. They could learn a lot from the Agile Manifesto if their goal is to spread around a vague-yet-appreciated manifesto around our industry.
Well, as much as I love clear structured frameworks, this one could use some work:
It’s not sure what it’s trying to be, talking about product and career? it’s more about how to be a PM in big tech than about building products.
It’s repeat of things that are already well known, which is fine as long as it adds value, but I don’t think it really does: it’s not comprehensive (omits important points), it’s not clear (see the discussion in this very thread), it’s not precise (some points overlap way too much), it doesn’t add any new context.
It is also very biased towards big tech and is not using ‘first principles’ to get at the heart of PM, which again, is quite well explored by others.
I think reading Cagan, Torres, Perri and others is going to be more valuable than this.
I suspect this was more about ‘compromise’ than consensus and is more of a marketing piece (as most things are with product school). And as a fellow Sr. PM, I don’t think people of my level should be creating frameworks on how to build great products. I learn a ton every year and reevaluate how I see and work on product constantly, can’t imagine how those people think they are in place to be creating ‘PM Manifesto’ over actual product gurus.
@RichardsonEva, The secret sauce from the Agile Manifesto was that it came from the personal frustrations of multiple individuals that had no corporate agenda behind. It’s genuine and to be honest very well though.
The Product Manifesto is a sales tool for Product School which to me killed the whole idea Deon the get go. The execution is very poor as it poorly resonates with the biggest pain points, we all feel on our day to days.
The first line itself is incorrect. You always ask what before why. You can’t ask why if you don’t understand the problem.
You derive goals from the product vision and strategy, not from user problems. I think they meant derive outcomes from user problems. Unclear on that.
Third point goes against the first. So now you start with what?
is fine.
Not sure what they mean on align on prio frameworks. Prio frameworks will vary based on your context, info, and what you’re prioritizing in the first place, as well as team growth and maturity. If anything, feel free to mix and match until you’re able to understand as much as possible about the decision you are making. There’s no silver bullet for frameworks here, and it irks me when PMs think a framework will tell you what to work on next.
Didn’t we already cover starting with a problem?
I don’t even know what this means.
Everything onwards is fine, but it feels like it isn’t part of a “product manifesto” - rather just good cross functional teamwork.
@NaomiNwosu, I don’t think you’re interpreting this correctly. What = the solution or product that’s to be built. Why = the problem that necessitates a solution (and the reason this solution can help).
Point 3 also makes sense if you interpret 1 correctly.
Correct, but how do you know why something is important if you don’t know what that something is? It makes no sense to say why before what. What first, then you figure out its value if at all.
I think you’re reading it too literally. The why isn’t “why is this product important”, it’s “why (for which problem) are we making this product (to solve)”. The what is the product/feature list as the solution.
The goal here is to customize a product or feature set to user pain points from the get-go with built in value instead of randomly iterating ideas where you have to see if they have any value at all. It’s supposed to foster agile thinking and be a quicker process.
@YuriRoman, The problem is what not why. why is the value, what is the problem.
Edit: I can totally understand your thinking here, and technically neither one of us is wrong. As long as the problem and the value it might provide if solved is the right level of detail that needs to be outlined.
I’m identifying the what as the problem not the solution. If the what were the solution, then obviously why would come first.
What = problem
Why = value of solving it
How = potential ways of solving the problem
However, to my point, the fact that we’re even discussing what the manifesto may or may not have meant and that it is open to interpretation (so to speak) highlights just how messy it is.
why is the value, what is the problem.