#features

Dogfooding

Wim • @wcools • • Part of Day 66

Just like it’s easiest to come up with a product idea by solving your own problem, the best way of figuring out how it should work is by dogfooding, i.e. using your own product.

For some of the problems we want to fix with Thymer it’s very clear how the app should work and solve them. These are things we’re currently trying to do with a plain text editor but don’t work well. In a way, the workarounds we’re using now because the app doesn’t exist yet are a sort of pre-MVP prototype, giving us plenty of ideas to work with.

For some elements of the app, we know what problem it should solve, but we don’t know yet if a solution we came up with on paper (literally, as a paper sketch is usually the first step) works really well. That’s where it’s helpful to build small prototypes to bring the idea to to life.

It doesn’t need to be complete yet, but just enough so we can actually start using these parts of the product and see if this matches the experience we had in mind. Over time a product will change a lot anyway, but making sure the core works really well by using it ourselves helps getting an MVP out with enough initial fans to get more feedback where to improve in the first place.

It’s not always possible to dogfood every aspect of the app yourself. Our existing product for example is used by companies 100x our size. In this case it’s still important to test the app, using a sort of test persona, i.e. trying to think like the end-user and about what their workflow might be. Another useful tool is populating the app with test data. If we’re a team of two and only have two items in a list, but our target audience persona works at a company of 100, what happens if we add a 100 items? Usually this goes a long way towards fixing the most obvious problems.

Thinking about these UX/UI issues from the beginning can feel like premature optimization, and of course launching a new product is always a bet in a way. But simply sitting back and waiting for feedback to roll in is not without risks. If an MVP doesn’t feel polished enough in the right places, users might drop off before you get to hear about these issues. Another problem is that fundamental design decisions regarding the very core of the app are very costly to fix. To take the example of our existing product again, we originally shipped with a permission system which was too complicated when teams had dozens or hundreds of users, and those are our best customers! As you can imagine, permissions touched pretty much every part of the app, so we could have saved a lot of time getting this right from the beginning and not having to change it later on.

You can usually tell when products or services aren’t really used by those who designed it. They’re often confusing or come with very obvious mistakes, which everyone would run into it, if only it was used enough. The same is true for individual features within an app. That’s why we try to avoid having too many core features we can’t dogfood ourselves.

Early user feedback

Diederik • @jdvhouten • • Part of Day 65

When you launch the first version of your product it’s likely to have serious flaws. If you want to discover what these flaws are you’ve got to figure out (a) what your users use your software for and (b) what changes you need to make to make them happier.

This sounds trivial, but it’s not. Especially when you’re busy building you can easily forget to pause and think in this critical phase and shred your chances for future product/market fit in the process.

First, you want to know what your users are trying to accomplish. This tells you if your users are who you anticipated using your software. If you have the -right- kind of users you want to figure out if your product website is targeted at them, and if your marketing efforts are successful at reaching them.

What do I mean by “right users”? Well, very early adopters tend to be different from the users you’ll get down the road. Early adopters are more technical, care more about power-user features, are less inclined to pay for software, and more likely to give extensive feedback. This initial set of early adopters is really valuable because they are so willing to help. But in most cases your core customer base will be different and also have different priorities. This mismatch is dangerous. Early adopters can lead you astray.

It’s not just early adopters that are unrepresentative. Any users that use your product in ways you hadn’t anticipated are dangerous to listen to. It’s too easy to get persuaded your app needs to grow towards a very specific niche, when really, by doing so you alienate 90% of your real user base. Always listen carefully to all feedback, but if the feedback comes from the wrong type of user it’s best to stay the course. If you really need to make a big change in direction your users will continue to remind you, so no need to do anything rash.

The world is a big place. If your first 100 users are lukewarm about your app it could mean that your app stinks. But maybe your app is just confusing to use for the first time. Or maybe your website gives the wrong impression. Lack of enthusiasm is not a great sign, but neither does it mean you have to pivot or redesign or start over. Minor tweaks will do. Look for a new set of users from a different pool, and see if you get a better reception.

Remember that users who give feedback unprompted are outliers. You’ve got to reach out to the quiet users, too! Track, in the most primitive way, whether users are active. If you have users who use your app every day for a month that’s a very clear sign you’re on to something. Email them, and ask them what the #1 feature is they’d like to see. It’s so easy to do, and you might discover that this quiet set of users are your core market and deserving of your full attention.

Solicit feedback in the app itself. Add a feedback button. Maybe add a poll so users can vote on something. Lower the barrier to give feedback — any feedback — as much as you can. This way you’ll get feedback from a wider group of users. And be really responsive and thoughtful in your emails to users. Most people expect poor customer support, so they won’t go out of their way to write down what they think. If you get the chance to surprise people with good customer support they become way more likely to suggest improvements to your product.

However, be weary of people who email you pages of ideas but who haven’t really tried your software yet. It’s a lot of fun to talk to people and to get excited about the different directions your product could go in. But it’s also a distraction if this conversation is with people who haven’t really explored your product. When people have a pressing need they really try to use a product to see if it solves their problem. They’re willing to put up with flaws and shortcomings in your product as long as you get the vital stuff right. And if they haven’t tried your product that tells you something. Which user sends the feedback is as much of a signal as the content of the feedback.

As for the features/changes you want to make, we’ve written about that before. In short: make the first impression really good and nail down the core user experience. Many good features you won’t have time to build for another year or two and that’s normal.

Wild ideas for Thymer

Diederik • @jdvhouten • • Part of Day 48

When you’re working on your first prototype for a new product you’ll inevitably come up with many wild ideas. It’s just part of the creative process. If you are a disciplined you won’t let yourself get distracted by actually building any of them, but it’s fun to think about what your product could be like one day.

Right now we focus 100% on what is strictly necessary to get a prototype done. The prototype has to have just enough functionality for us to get useful user feedback, but no more. Then we can iterate based on that feedback and fix flaws in our design.

That means we can’t add any of the stuff below to Thymer. Not yet, anyway.

Blog plugin. Use Thymer editor to write simple text based posts + maybe pictures. Render to static .html to publish.thymer.com or something like that. Maybe let users write public and private blog posts. If the Thymer editor is really good and you already have your notes in it, being able to share them makes sense. You could also share posts privately, with end-to-end encryption. Users would then need to enter a password to decrypt the shared note. It’s an easy plugin to write, and maybe it’s something people would like.

Kanban board plugin. Instead of rendering Thymer tasks as a vertical task list we can render them horizontally with tiles like a Kanban board. Add support for drag&drop. Enjoy easy planning.

Thymer is effectively a tree editor. Allowing users to view/edit their data in different and visual ways is probably an easy win for us.

Transclusions. A transclusion is when one document appears partially inside another document. Digital documents don’t need to be strictly linear, and it would be very cool to have something that’s more powerful than a plain hyperlink to another part of your Thymer document. We already need to make something where a planning view (an ordered list of things you plan to do next) can have items from anywhere on your document on it. Generalizing this concept and adding full-blown transclusions to Thymer might be worth it, because it unlocks opportunities down the road.

End-to-end encryption. Thymer is an offline-first app. You download all your data when the app loads, and it syncs in the background when/if you’re online. Because the app has to work offline the server doesn’t need to get involved during normal operation. That means we could just encrypt all data locally. Then the server would only see the tree structure of your document, but nothing content-wise. The major downsides here are that we won’t be able to offer server-side search, a practical API, or 3rd party integrations if the server can’t read the data. Personally I strongly favor apps that put encryption front and center. We’ll have to wait and see what the beta users think.

Roadmap plugin. Thymer will get a personal schedule where people can add tasks they plan to do Today, Tomorrow, Next week or whenever. But sometimes you want to do higher level and long term planning. We could make a plugin for that. It’s unclear at this point how it would work exactly, but if you have 5 or 10 people in a team you want to have some kind of overview where you can see what’s happening in broad strokes. Maybe this overlaps with Change History and Meeting Mode below. I don’t know.

Poweruser console. When you’re working with your own software you do bulk actions all the time. You find some objects based on some criteria, and apply some changes with a for loop. A REPL or a browser’s debug console are huge for productivity, but consumer apps never offer something like that. Why not? You can tediously make changes with point and click. If you’re lucky the app allows you to bulk move/delete, but that’s where it ends. I’d really like Thymer to have a REPL. Then users can do whatever they like with their data. Users of productivity apps have their idiosyncrasies, and the more Thymer can accommodate how people like to work the better.

Change history. Some way to see a what changed in a condensed way. If you get back from a holiday you want to see what people have been working on. How has the schedule changed? What items have been deleted/abandoned? Who is currently working on what? What decisions have been made in your absence? Ideally, you’d get some kind of executive summary that isn’t too long. Because the Thymer document is a tree it’s reasonable to to assume things higher up in the tree are more abstract/high level. Maybe a summary view can condense changes based on that.

Emoji Flags. People want to use their task list in different ways. We won’t be able to anticipate all our user’s needs, but we can provide people with options to organize their tasks to their own liking. We can store arbitrary metadata in tasks. Allowing users to choose their own status emojis doesn’t seem like a big stretch. Want to give a task a ⌛ or 🐳 status? Sure, why not.

Meeting mode. During a meeting some tasks get deleted, new tasks get added, tasks get assigned and reassigned, and people’s schedules get changed. You want to see what has been changed during the meeting separately from other changes made to the Thymer document throughout the day. Ideally meeting notes that contain the rationale get linked to the changes made to the Thymer document. I don’t think it makes sense to have meeting notes that duplicate the changes made in the Thymer planning. But when there are no meeting notes at all the “why” goes missing. Somebody who hasn’t attended the meeting should be able to see what has been discussed and what has changed as a consequence. I don’t think there is any product out there that gets this right, so it’s probably more difficult than it looks.

Any project, even something as simple as a todo list, will grow in scope if you let it. You can’t just add every random feature to your product. Your product will lose its cohesion and you’ll never launch. But you can write down all your half-baked ideas. Once you’ve got some users go back to the list and see if you can actually make some of your wild ideas reality.