Today, we're going to be talking about a topic that I never thought I would actually be talking about on this podcast, but we're going to talk about how to be successful if you find yourself stuck in a waterfall environment. Welcome to Lessons in Product Management. I'm your host, Jon Fontenot. And today's episode actually comes from a podcast listener, subscriber.
Who left me a comment on Spotify, which I encourage you to do. I love the interaction. I love questions. I love comments. So if you're listening on Spotify or can listen on Spotify or. just feel like going drop a comment go over and subscribe on Spotify leave me a rating and review while you're at it just because I appreciate that and it helps other people find us I think the algorithms like that kind of stuff
But Jonathan Leslie left me a comment, a couple comments actually, which I appreciated. One of them was... suggesting and requesting an episode around how to be successful if you find yourself stuck in a non-agile environment like Waterfall, which I thought was a fascinating question.
I guess there's still lots of product organizations out in the world, especially in some environments that work in waterfall, which makes sense. I actually know a PM who... is in kind of the the sports industry right with like sports apps and you know once a season is over are people really going to be using that app
year round or are they going to come back once that season starts up again and you can guess what kind of app it is i don't think it really matters if i told you or not but But anyway, so think of something like fantasy football that only happens for a few months out of the year.
What do you do for the rest of the time? You probably spend the rest of the year preparing for the next season, and you might have some incremental releases, maintenance stuff that happens, but what do you do in that time span? And, you know, it's not just fantasy football. There's other industries and applications and just companies that operate under that world where back to school time.
In August, typically, there's usually big releases in the education space. So you name it, there's lots of situations where you might find yourself in a waterfall type of environment. And it was incredibly thought provoking. because you know people bash on waterfall all the time and you know as i started researching kind of thinking about prior conversations i've had and just asking myself what would i do if i was in this environment
I have a couple scenarios. So I have the ideal scenario. This is, do you have humble leadership who's open-minded and willing to adjust and experiment and try different things? Or are you in a less than ideal environment where things are pretty rigid, but maybe there's some opportunity to influence some change? So I'm going to kind of come at it from both of those angles, starting with the ideal scenario.
Okay, so in an ideal scenario if you have the opportunity to influence hearts and minds and processes Whether you're an IC or a leader who might actually control these processes What I would suggest is making discovery part of the waterfall planning process. So one of the things about waterfall is there's a lot of in-depth planning up front, and then the rest of the time is executing against the plan.
And inevitably things change, but you try to minimize the amount of changes to the plan that you had. Ideally, if you learn new things that should shift the plan, you should. shift with it but that doesn't always happen a lot of times in waterfall environments things are pretty rigid we have a plan and we execute against the plan and if the plan doesn't work then six 12 months later whatever that cycle is then
We shift then, but we execute against the plan, which in fairness, there's actually scrum processes that on a smaller level operate the same way. And I've worked in companies where we've had to change those processes because the rigid approach actually was... was screwing us and putting us in a spot where we could have missed our deadlines because of silly processes that we should have never followed. And fortunately, we had engineering managers who agreed and saw the stupidity in the process.
And we changed it. So hopefully you're in that kind of ideal scenario where if you bring honest logic and try to make things work, I always suggest.
try everything you can to make it work so that way when you go back to say hey this isn't working this is what we're trying and this is what we're seeing and this is the result that i'm seeing as a As a byproduct of us following this process, it usually resonates more than just like immediately pushing back on something because conceptually you think it's wrong.
I digress I'll take a breath here for a second get a little passionate about that especially since it was relatively recent that I dealt with that but number one under an ideal scenario I'll go back to it
try to make discovery part of the waterfall planning process. And what do I mean by this? I mean, validate the biggest assumptions first. If there's assumptions you have dealing with the underlying core... technical architecture or design architecture, whether it's information architecture, whether it's, you know,
tech underlying technology you're going to use like what's the the data schema are we doing are we building in a monolith or microservices architecture some of those big things that are hard to come back from which you've already gone down that road Whatever assumptions you have that could lead to one decision versus another, try to validate those assumptions first as part of the planning process so that the team can get started building that foundational layer.
while you go off and start testing some of the less risky assumptions and so you kind of have kind of a dual track mentality even in waterfall where you have a plan But really the upfront planning is to de-risk some of those big assumptions so the team can get started. If you need the entire plan baked out, that's fine. Again, test those risky assumptions first and then like outline the whole spec as a hypothesis and just set that as a cultural expectation that this spec is not.
Stone tablets from on high this spec is a hypothesis that could change as we learn Okay, so even if you need to have that whole plan That's fine. If that's part of the process, if that can't move, build it. It's probably a good thought exercise. You're probably going to be wrong. We all know that. So let's exercise some intellectual honesty.
and call it for what it is, that it's one big assumption or one big hypothesis. All right, so that's the ideal scenario, that if you're in a waterfall environment that might sound pie in the sky, you might... you know be in a situation where culturally that just seems so far from reality that it's laughable if that's you keep listening the the less than ideal path or suggestions that i have
is if you're already in flight with a big project, right? You've done the whole spec, you're executing against it, things are rigid. Take the time to bring those designs or early prototypes to customers for feedback. It's too late. The ship has sailed. Things aren't going to change. But you might as well start pre-planning for the next release's planning cycle.
So when you get to that planning cycle, if you're not given the space to do discovery, then you're kind of a cycle behind, but you're not perpetuating a bad cycle. You're getting feedback about the stuff that you're going to ship. as you're working on shipping it so you can figure out where you're wrong and start baking that data into your next cycle's planning.
All right. So even if you have to do it kind of like ask for forgiveness instead of permission, if discovery is frowned upon, which is incredibly ironic to me in companies where PMs don't want to do planning or executives don't think.
i mean discovery or executives think it's too expensive to do research and discovery because they don't really understand what it means do it anyway and ask for forgiveness later because they probably won't care when you actually figure out that you're way off the mark and you actually have the data to course correct so that said if something's in flight use that time to go start doing the work that you should have done from the beginning
You're going to be late, but it's better than not doing it at all and continuing to ship things that always miss the mark. Number two, even in a less than ideal environment, Document your assumptions in that large spec that you're currently working on and share those broadly. Start kind of forcing this into the process of saying, hey, here's what we built and here's all the assumptions that we have. These are things that are...
Not obvious. These are things that are not validated. These are things that when this gets to production, we're not sure how it's going to be received. That should start raising alarm bells in and of itself to people in the company. Common sense hopefully would prevail. But as the expression goes, common sense is not always common. But hopefully it does.
Nonetheless, at least you have it documented and you've shared those assumptions out. So then after you release, you can test those assumptions. Did we get the adoption? Did the customer segments that we thought would use this, are they using it? At what rate are they using it? What frequency are they using it? And if you have a lot of disproven assumptions, leverage that fact, leverage that data.
to suggest changes to the current process to try to get to that ideal scenario where discovery and some of the bigger, more risky assumptions get tested as part of the planning process. versus just a whole bunch of stakeholder-driven assumptions getting piled into a document that you have to organize that eventually get shipped, and you may or may not get lucky with the business outcomes that you drive.
There's really nothing wrong with planning. There should be planning no matter what type of delivery process you run. And like I said at the beginning, some industries, some situations, annual releases might make sense for you. But the question you should ask is, what am I doing with my time between releases that can make or break success? And this is true whether you're in waterfall or agile.
Agile methodologies that ship on a two, four, six week cadence, whatever it is, they just allow for reality to hit you in the face sooner than later. Waterfall where it's like, if it's quarterly, semi-annually, annually.
those feedback cycles those feedback loops just take much longer to get to so you have a whole lot more time that goes by before you learn what the truth is so that's really what the big difference is and if you can start leveraging data to push to and push for getting that feedback earlier than later and just tweaking the process slightly you're going to benefit from that so
Again, I really appreciate the comment. I appreciate the questions. I hope you enjoyed this episode. If you are in Waterfall, I'd love to hear from you and just see, does this resonate? Does this make sense to you? Um, is there, is there any followup questions you might have based on the advice that I've given? Um, but yeah, in general, if anyone wants to hear specific topics, get my thoughts on specific topics or, uh, want to recommend guests.
for the show. Again, I just like the engagement. I like to hear what the community is saying. There's thousands of you that subscribe and that listen to this. And I kind of speak into a microphone sometimes. I'd love to hear from some of you. So thanks for joining me today for another lesson in product management. And we'll see you next week.