@wcoolsSometimes you’ve thought a design over many times, made a bunch of sketches and think you have a clear idea about how everything works. But sketches and prototypes are very rough by design, so it’s easy to look at the same sketch in different ways, or discover some parts of the concept need more work when you start working on the nitty gritty details.
Although everything about a startup and launching an MVP shouts “ship ASAP! ship yesterday!”, quite often taking the extra time to think things over a bit more helps making sure you take the right turn, which saves a lot of time down the road.
Today we spent most of the day meeting and going back to the drawing board about some design decisions for Thymer’s core features.
Having worked on the app a bit more by now, what features do we really find important? How do we keep the scope for V1 small? How do we balance the fine line between making a product too narrow to be useful, or making it too broad so it automatically gravitates towards becoming a platform with unlimited scope. The USP of Thymer is it’s a powerful IDE for people to get things done. Part of the “internal USP” of this product is that it won’t take years and VC funding to build. We need to make both of them work.
One feature we talked about for example is related to dates. Thymer has some notion of dates, which is important for planning. Not doing the “hard work”, actually thinking through what this means and how it should work, most often leads to the wrong solution by default: the one easiest to come up with and hardest to make.
In this example, that would be a calendar. But jotting down some thoughts on what to work on tomorrow is different from a tool where people schedule an appointment with multiple participants using a start time in timezone A and an end time in timezone B. It’s not Google Calendar, which is a completely different product in and by itself. Not only would building all of that be way too much work, it would offer nothing new, and it would make the product less interesting, watering down the vision.
So we looked at how the concept of dates within the scope of the app is actually useful, what parts you need, what parts you don’t. In what way it wouldn’t conflict with using other tools like an existing calendar on the side.
In terms of scope we also looked at some other features we most likely won’t be able to build in V1. For example, in the case of end-to-end encryption (E2EE), we need to make sure that we don’t take decisions now which will rule out being able to encrypt data on the client. Another example was mobile access. Although we can’t launch a dedicated mobile app when we launch V1, we thought about whether a companion mobile version, just covering the most important use cases for on the road, would be compatible with our idea of the core version of the app.
We made good progress refining the vision today. Really look forward to launching V1, but there’s also still a lot left to build!
