Project Weeknotes Part 1: Problems
For the past year, I have been writing a summary of the past 7 days weekly. This time of reflection has been really helpful for reaching my goals and developing as a person. From the book Show Your Work by Austin Kleon I would share this with my inner circle of friends at doms-weeknot.es, but it was a very janky set-up and needs updating badly.
Alongside that, I have been working on Flutter, a framework for building apps, with the goal of quickly developing apps for the purpose of prototyping and validating via Minimum Viable Products. Therefore, in deciding to build a new version, why not leverage the need for practice and create the new weeknotes in Flutter.
Where we are today
Go visit doms-weeknot.es and you will get the gist of it pretty quickly, a quick overview for everyone to read. It was built using the Python web framework Django, using markdown to format pages, and hosted on Heroku. Now I could just describe the functionality but actually decided to go through the processes and techniques of a Product Manager in order to show how to go from idea to app (basically a plug for my business Chuffed Solutions). So let’s start at the beginning.
Scoping
Here is where we define a feature, fix, improvement or entire product. We look at asking the following questions:
Why does this need to exist?
What does the value delivery look like?
What problem are we trying to solve? and for who?
What are we trying to achieve?
What are the users trying to achieve and what will they get?
What assumptions have we made?
What is a state of doneness?
What work is to be done?
How do we know if we have succeeded?
What can we expect from the future?
This order is for the sake of all stakeholders and people working on it but is not the order that I will write it. Therefore as I write everything up it will be the process I take to complete. So, in this post will just be looking at the problem we are trying to solve and for who.
Problems
Every product solves a problem, and with that everything has to start here. Building products has led me to realise that writing good problem statements lead to teams being bought into an idea and a clear direction to move in. Here are some rules to follow:
Write as a narrative form
Write from the perspective of every persona involved
Do not include a solution inside of it
Avoid technical descriptions
So in my case here are my top-level problems:
As a person who wants to personally develop, reflecting on what I have managed to achieve, where I fell short, and what I have learnt along the way is vital to be working towards a better me. But I find it hard to bring people in to advise and hold me accountable, because lengthy text messages and emails may go unread and be interspersed with day-to-day conversation. This makes me feel like I am alone on my journey.
As a person who wants to personally develop, I want to be aware of my successes and wins so I know I am becoming a better person. But I find that it is easy to forget where I have achieved success as in the noise of the day-to-day it can get lost, and also the negatives can garner more attention and therefore overshadow the positives. Therefore I often feel that I am underachieving and not working towards a better me.
As a person who has a someone close to me who is on a personal development journey, I want to know what they have been up to so I can offer encouragement and support, but catching up could be sparse and vague as times to talk about their journey can happen only every so often. I then feel that I cannot help or support where needed, and worry things are not moving along as they should.
From here whatever I am proposing has to serve to solve these problems directly, otherwise, it goes in the bin.
Now if I was intending to take this to market I would go through a process of validation, that is to go through every problem statement and persona and find every assumption there is. Then go out and talk to people, and look for how true these problem statements are, if they are off I will rewrite problems, pull out assumptions, and rinse & repeat until I have no more assumptions, at which point I will consider it in a state of “validated as much as possible”.
End of Part 1
With our problems defined (and we will pretend that it is validated for the sake of this example project) we can look into the next part of scoping, Purpose.
