After context and understanding of the value that will be delivered, the next stage is to define the Work to be Done. This will be the “What” in the piece and is a list of things that instruct others through a to-do list.

Work to be Done

We can be indirect and direct in how a piece of work is completed. Sometimes I have an explicit direction to an addition or change. Still, on other occasions, I am implicit and allow people to be creative and feel empowered, leading to an excellent implementation that I may have never thought of.

My approach is to write a bit like code but in prose-like form. For example

• If a user logins in for the first time, then present the welcome tour

  • If they select to go through the welcome tour, then …

  • If they click skip, then take the user to the home page

• If not a first-time login, then open the last page viewed.

  … etc.

This will explain to any stakeholder how something is being built and every condition in the logic behind the work.

For Project Weeknotes:

• If a user goes to https://doms-weeknot.es, they are presented with the most current reflections and planning below the previous 4 entries.

• If a creator goes to /login, they can log in with an email and password.

• If a creator logs in, they are redirected to /notes, there is a floating action button to add new Weeknotes for this week.

  • If the floating action is clicked, then a create Weeknotes page is opened with the ability to:

    • Add a title

    • Add a date (defaulted to today)

    • Add an emoji or emoticon

    • Add the reflections and planning for the week, written in markdown

• Also, when the creator logs in, a list of previous entries as Title and Date, are shown from newest to oldest.

  • If an entry is selected, then it can be edited.

• When a Weeknotes is created, track the version type of this data structure so iterations can render differently.

Additional Stuff

Assumptions

I like to point out everything that is not known for certain and needs additional insight to be confirmed, basically risk management. I don’t do this to make a case not to build something but to what is needed to be included to gather the data to obtain that insight. Also, the size of the build is direct to how certain I am on the level of truth behind the work itself.

Moving Forward

Sometimes the additional context needed to be given is where we are going on a larger scale. Writing what is out of scope helps to inform how to set up the infrastructure behind the piece to make future iterations easier, and sometimes one of the Moving Forward points ends up being a lot simpler and can be added to the scope.

QA Tests

When in an involved piece, I find it a good communication tool to just run through the tests that need to be done to explain flows from the user's point of view.

Open Questions

Whenever a piece is moving forward, stakeholders will have questions that need to be asked and meta-questions to be asked about what they are saying. Keeping a log of them in the scope will help to flesh it out.

End of Part 6

So this is how I approach scoping, and to be clear, every Product Manager does things differently and is subjective to what it is you are building. With that, one thing is very true, if you are finding it easy to write and do so with confidence, then you are on the right track.