011 - revisiting the product roadmap
I spent a couple of my earliest posts talking about what I would call "product management". For those who have never heard the term, "product management" is deciding what features to add to the product and in what order.
In those first few weeks I was faced with a huge blank page and it was very overwhelming to decide which features to build first. So, I spilt a lot of ink describing various heuristics to use for making product decisions in the early stages of a software product.
It's three months into eno's development and I have stronger convictions about how to prioritize feature development. As I started to actually build the product, it became clear that certain features I envisioned were foundational to the technical architecture of eno and others were not. I use the word "foundational" as in a building's "foundation" because eno's code will all be built on top of these foundational features. This isn't the result of my own decisions but inherent to how these features work. They may or may not end up being the most loved features in eno but I kind of have to build them first.
To be concrete (pun intended), there are four features that form this foundation:
- Multi-document editing environment
- Live templating
- Integrated version control
- Collaborative editing
As I have worked on these, I have learnt that they are inextricably linked with one another. They must be built as a single cohesive unit rather than in sequence. Specifically, each of these features is tightly coupled to the underlying data model of eno.
At this stage, I've laid out the scaffolding for a data model that can power all of these and I see a fairly clear path to building each feature out to a feature complete state.
Finding a first user
Now that I know what I am building, it's probably a good time to figure out who would want to use it. That sounds like backwards logic and it probably is. I think it's defensible though. I have a long term vision for an eno that is so great that anyone working with documents will want to use it. That's at least a few years off so I need to find some checkpoints along the way. I need to find a first user who might be interested in using eno long before it is feature complete.
There are some clear requirements for this first user. First, they must have the potential to get an extremely high amount of value out of eno. Anything less than that and they would be insane to risk working with a brand new, unproven product. From this I can extrapolate a two requirements:
They spend a lot of time every day working on documents. A tool to to help them do this would have a huge impact on their day-to-day.
A lot of their work has a highly formulaic pattern that eno could do much faster and better with its live templating and mutli-document editing features.
If convincing a person to use new risky software was hard, convincing that person's coworkers to use it as well is even harder. For that reason I have a third requirement:
- Most of their work is done alone.
Finally, there is a business reality. If a single person with a highly esoteric profession came out of the woodwork and satisfied this list to a T, it might be a bad decision to build an entire business around them. We need to ensure that we can build a modest revenue stream from this initial group. Thus, our last requirement:
- There are either (1) a lot of this type of user willing to pay a small amount of money or (2) a few of this type of user willing to pay a lot of money.
Throwing in the towel on terminal UI
In my announcement for eno I stated the following:
To begin, [eno] will be a terminal UI application. For non-nerds,
this means it will look like something out of the Matrix. I don't
think anyone will want to use that version but it's a lot faster
to prototype in. I can make it pretty later.
I've decided the time to make it pretty is now. As I start to think more realistically about getting actual non-technical professional's to use the product, I realize the terminal UI will hamstring me every step of the way. eno needs to look awesome. If nothing else, it inspires confidence. Ideally, it brings joy to the people who use it.
Though I expected to do this eventually, I thought it would be later than now. I was hoping to build out a fairly feature complete prototype in the terminal before investing in a full graphical user interface (GUI). As it turns out though, building a terminal UI isn't exactly trivial and I am starting to feel the burn of investing development cycles in something that I will ultimately throw away.
The downside is there will be an immediate slow down as I spend time figuring out how to build a native GUI application. This means learning how graphics rendering works for the first time and figuring out font rendering - a notoriously frustrating area of computer programming.
The other side effect I fear is that a non-terminal UI removes many constraints on my design. With my work so far, there where many times where my mind ran away with ideas of how eno could look and feel. These tangents were quickly cut short because they were simply not possible to create in a terminal environment. A terminal is a giant grid of squares and each square can only be one colour and have one letter in it. By moving to GUI I might be opening Pandora's box by allowing myself to consider basically any look and feel I can dream up.
Subscribe below to get notifications for new posts.
We also have and RSS feed