Many Product Development conversations focus on process. Specifically in software, teams discuss the pros and cons of waterfall vs. scrum vs. extreme programming vs. lean vs… whatever new methodology springs up next. People build tribes around them, defend their tools, champion a certain way of thinking. I don’t think these aren’t necessarily bad conversations to have. Any process that you are 1) excited about and 2) can commit to = better than none.
The ‘right’ process depends on your particular challenges: each addresses a particular organizational need (to reduce risk, build the right product, reduce waste, staying flexible). Even the much-maligned waterfall process is appropriate for certain teams building certain products. Take stock of your organizational goals, your team’s strengths, and ability to change; commit to one of these tools and it will probably work for you. You probably can’t change overnight; the bigger the company, the harder it will be to change how your work. But you can make constant progress towards that goal.
I would add this: whatever you choose, periodically evaluate your process, assess what’s working and not, and be prepared to iterate on it. Adopt a learner’s mindset about the way you make products, not just the products themselves. Adapt it to your specific needs. Just because ‘it’s the hot new methodology’ or ‘Spotify does it’ or wherever, doesn’t mean it will work for your team. Two week sprints in SCRUM too long? XP promotes weekly sprints. The BaseCamp team uses 6 week sprints. Can’t get your dev team into crafting user stories? Run an occasional one-off design sprint instead.
To me, “Being agile” means accepting that you don’t have all the answers, actively seek out them out, and be willing to change. Fundamentally all businesses are about solving the customers’ problem; a PMs job is to solve the business’s problems.