Designing a Minimum Viable Product from scratch

Introduction

I spent some time Outside this week listening to some birds in the park. A greenfinch, goldfinches, and a blackcap, plus the usual blue tits, chiffchaffs, and an absurdly loud wren. I also started designing a Minimum Viable Product (MVP) from scratch. Nothing like a bit of refreshing contrast!

Discovering the work

There is an urgent mission behind Progress RPG. It is no longer a personal project, and so I have to get serious about making progress. People are in need of support right now.

Others have urged me to delegate and write down my Standard Operating Procedures to develop the app more quickly, but I didn’t know where to start.

My breakthrough in deciding which Progress features to prioritise developing came when I devised two simple questions:

1. How did I know to choose this task in app development? (discovery)
2. How did I know how to do it? (performance)

The answers weren’t exactly sophisticated:

1. It seemed like a good idea at the time
2. I bashed my head against the task until one or the other gave in

I have used LLMs (aka AI) to teach myself how to write code. This has many downsides, one of which only became clear when I looked at the next task I had assigned myself: improve an existing feature to minimise future work. When I asked myself how I knew this was the most appropriate task, I realised that the feature already worked just fine. Without having defined the work in advance, however, it seemed like the sensible next step. I was working like a developer without a boss.

Designing an MVP

When I discovered I was jumping from task to task, I decided to spend a full day designing an MVP from scratch. I allocated an hour for planning the day, two hours for the work, a lunch break, and another two hours for work before wrapping up. I got super excited!

That morning, after planning, I spent about half an hour each on identifying user needs, mapping the required behaviour for the software, and extracting essential interface elements and functionality.

It was all going well until my first session after lunch when I felt fatigue kick in. It was frustrating, having to stop and resume the next day. This is the reality of living with chronic fatigue from burnout, from which I’ve been in recovery for 18 months now.

Why now? Why not earlier?

I started building this for fun five years ago, but I quickly realised I was building the tool I’ve been dreaming of for most of my life. As I realised the potential benefits for others in a similar position, I started a gradual transition from personal project to public platform.

The concept and the design have both changed massively over the last two years of serious development, but they have always led development rather than being led by user needs. With no development or entrepreneurial background, I didn’t fully understand the ‘Minimum Viable’ aspect of the MVP, and also confused it with alpha, beta, and public launch. It took me a long time to realise that I wasn’t actually building an MVP at all.

Major changes

Designing the MVP in this way surfaced some big decisions. I noticed that none of my notes mentioned the need for characters in a separate game-world. The symbiotic link between a user (a real human) and character (digital inhabitant of a medieval game-world) has been a unique feature of Progress since its inception. In conversations with users, however, the concept has often needed explanation. I have therefore made the decision to remove it from the MVP.

What’s next?

• Pivoting consciously from ‘developer’ mindset to ‘leader’ mindset. This means prioritising relationships and strategy, and using tools to reduce time spent coding.
• Asking testers for feedback and iterating faster.

And now I am going Outside again to listen to birds.