This Time, Waterfall Saved Me!
The background of this story is that we just acquired another company, and we were asked to deliver the same invoices services to the clients that would be migrated to us. Before the migration, our existing invoice products worked totally differently. We had only two months to release it on production. After one day’s daily, one backend developer reached me on Slack.
“Hei Tianran, how the specifications on the invoices should be like if this happens?”
He just describes a new scenario to me that is not mentioned anywhere. Although, to be honest, I have no idea either, because I know little about how we charge our clients in Sweden.
“I need to ask our sales, and I will get it back to you soon.”
Meanwhile, our salesperson in Sweden reaches me.
“Hello Tianran, can you confirm this will be on our new invoices? I need to confirm it with my clients.”
After reading what he has asked, this seems to be a new requirement that no one ever mentioned before.
“Is this something new from our clients? Or did I miss anything?”
“No, this is a new one. By the way, I have two new requirements from them too.”
“OK, before you tell me more, I’d like to ask how we should charge them and what the specifications should be if this happens?”
“I think you need to ask the Finance team about it, this is related to VAT, and I am not familiar with it.”
“OK, thanks, I will ask about them. And what are the other two…”
After the conversation with him, I join the weekly call with our finance team. But they start with a question as a greeting:)
“Hi Tianran, what is the release date of our new invoices?”
“Well, you know, tech products are hard to be predicted precisely, but I think we are most likely able to have a test sample out in two weeks. And I have a question, do you know how VAT should be listed on the invoices if…”
After all, we realize we are uncovering an entirely new scenario, which did not exist before the acquisition, therefore, not discussed and refined either.
What do you see from the conversations above?
I see product development is blocked.
I see uncertainties and risks are growing.
Furthermore, I see myself as a desperate product owner who can’t prioritize anything.
What exactly happened?
It is a feature that was adequately refined with the team. However, it is currently blocked due to the missing business logic of some unknown scenarios. Moreover, no one knows whether there might still be something else that we don’t know.
It is a service that existed for ages, and we are closing them and duplicating the same one to the same clients. We have no time and need to use MVP to validate anything. The final product has to be the one they expect.
It is a product that has no time for being postponed, and we have to deliver it on production without delays.
More importantly, agile seems not to work here in this situation.
Why do I say so?
Requirements are clear and strict.
Design and planning should be more thorough and careful because we can’t take the risk of modifying anything before the deadline.
Compared to the build-validate-learn methodology, we have no time and no need to validate any hypothesis because all the requirements are precise and expected from the clients.
Does it sound like a Waterfall to you?
After our Retro, we decided to make a change. (At least the Retro still works, huh?:))
Rather than doing evolutionary development, we plan our remaining projects as heavily as possible. PO starts with documentation, and critical stakeholders start joining refinement. Everyone has to agree on what we will do, how it should be done, and what we won’t or can’t do. We try to challenge stakeholders as much as possible to cover all corner cases. Besides, all the decisions are written and documented.
And, it worked!
What has changed?
At least developers are happier. They wouldn’t expect 100% accurate documentation, but they do expect something with more details than a JIRA ticket or user story, especially when there are huge dependencies between features. If something we miss or needs to be updated, PO will update the documentation with versions. Version control is also the key here.
Stakeholders are happy, too. Most of the time, they care more about when, sometimes what, but no one cares how. However, on the other hand, they know the best what the team should deliver because they are either experts in an industry or experienced account managers. By having refinements together, they know better about the progress. Besides, they can tell the root reason to the team why something should be built in a specific way.
At last, and most, I, as a PO, am saved! I am confident to talk to developers about the requirements and talk to stakeholders about the delivery time. The key is that I can manage the priority now, based on the criticality, effort estimation, and actual implementation. Risks and uncertainties are under control.
Eventually, we managed to deliver the product on time with a few hiccups. However, the team, together PO and developers, keep the promise, in my opinion, that is the achievement we should celebrate for.
To recap, as a PO, if you are struggling with some projects or working in a so-called feature team. Maybe try the Waterfall approach if such criteria are met:
- Requirements are clear and precise, not to the team, but the clients! Meaning your customers know exactly what they want to have. It happens typically to B2B areas, like invoices, taxes, and customized or localized services.
- Requirements are heavily dependent on each other. It is hard to split the user story, or the user story won’t work when those dependent requirements are complex. Documentations with versions might work better for the team.
- When you don’t need to validate any hypothesis or new product ideas, especially when the acquisition happens, you either copy the same product or drop it entirely. DO NOT provide something similar but different, though you THINK it is better. Remember this formula: [User Experience] = [New Experience]-[Old Experience]-[Replaced Cost]
- When you have a clear and strict deadline, you have no time to waste due to a lack of a proper plan. Planning is the key to ensuring a successful release.
- One extra tip, use the Waterfall approach but try to keep Agile as the mindset behind. What does it mean? Internal tests or Hi-fi prototypes should be prepared as early as possible. It should be taken place as frequently as possible. Build the prototypes as the validation tool and learn the feedback from stakeholders. Is it what they (and eventually the client) want?
Agile is probably used in every tech company. Everyone knows it is not the panacea, but it is still believed to be one of the best approaches for all the tech products you are building. On the other hand, Waterfall sometimes represents an old, legacy, and out-of-date approach. However, this time, Waterfall saved me.
