Scoping out Ambiguous Work

I have faced something similar in my previous job and here is my thought process on approaching an ambiguous project. I'm pretty sure Alex/Rahul are far more knowledgeable than me on this topic, but I'll give it a try:

• Before jumping into design, are you taking a step back to understand the "why"? Meaning high level goals, key stakeholders, success metrics etc. Knowing why this project exists is essential context to have before doing any scoping/implementation
• To better understand the requirements, I would sync with PM/TL or teammates regularly to ensure alignment. Something I found helpful to say, "Here’s a few options I’m considering, and here are the tradeoffs I see [insert tradeoff 1] [insert tradeoff 2]"
• Once requirements are disambiguated, might be good idea to decompose everything similar to the decomposition video in the amazing E3 to E4 growth video. I would aim to break the project into several milestones with deadlines for each and regularly communicate this plan to the tech lead. I would err on the side of being conservative with regards to project estimates.
• Finally, I document the proposed design. I send it to the team for approval. Once it is approved, I begin execution.

In summary, I find it helpful to spend time understanding the problem before beginning the design/decomposition/execution. This way, it minimizes the chance I deliver something the team did not quite want.

This resource may be helpful: https://www.jointaro.com/question/MVyu85xVBvFAZFEdSosX/how-do-i-build-my-time-estimation-skills-for-project/

Hope this helps :)

Because you are a SWE, your first though would be technical, ditch that, the problem is there. If the requirements are not defined, this is your first job then.

You have to reach out to the stakeholder, identify main headlines, fill with assumptions, and split into milestone.

What you have now is something that may be 20-40% correct, then use it to circle back to the stakeholders, challenge what they say, let them correct it, it's a lot easier going with something already written, even if far from what they want, other than going with nothing and asking for requirements.

I can guarantee you, by this point, you might have something that's ~70% accurate. Go back again, and get their signoff. At this point, they will be willing to agree on that.

You will not get 100% complete requirments from the first phase, or even the tenth! So live with what you will have at that point, buffer for some last minute changes, and iteratively start the design. Good luck!