When I make new apps, I always try to check to see what is the riskiest part of the business.

Plus, I try to look for the fastest way to check that. I think like this for everything, including ideas for new apps, programming, and so on.

So, what is the riskiest part for me?

Motivation Risk

Motivation is the engine for everything. I believe this is the most important aspect of your work. If you lose it, it’s over. It is always reflected in your work.

Therefore, what I care about first is not losing my motivation during developments.

If I make something, I want to make something amazing. If I want to make something amazing, I need to keep going day by day. If I want to keep going, I need to pick something I can keep my passion for.

How is that measured?

My trick is to wait. I usually wait for weeks, even if I come up with something I am excited about.

When you get a new idea, you always get excited most at first, but after several days, that excitement could fade away gradually.

If you still have a passion for your new idea after a few weeks, it could be something that you wouldn’t give up on easily.

Technical Risk

Another important thing is to consider whether or not your idea is even possible to achieve with current technology.

You can’t create it if technology and ecosystem are not ready, no matter how much you want to make it.

This is also essential when I start programming something new. I always start from the hardest part, in other words, I want to start on the part of the project that I am not even sure that is possible to implement yet.

This doesn’t mean you must jump on the hardest thing at first, it means you find the most important thing and start from there.

It’s better to tackle on the most important and uncertain parts first, and skip the small things that you can predict.

It might feel good if you start from easy things you can do since you feel productive after seeing your progress. However, if you find out that the most important part of your app is technically impossible later, everything you did beforehand will be a waste of your time.

Demand Risk

This is the most difficult part to check.

The two things above are something you can see by yourself, but demand is different.

The only way to check this is to ship your product. Shipping takes time, that’s why you should start from the riskiest parts to minimize the risks.

There are tons of uncertain things in this world, including your health, environments, change of the ecosystem, and some things you never imagine.

So, skip the easy and small parts of your project, and start from riskiest things in easy and fast ways.

It is now the era of video. You see lots of promotional videos from dozens of new startups. Twitter co-founder Jack Dorsey also said “Don’t let users read, let them watch” when creating promotional sites.

I can intuitively tell this is the right approach. Nowadays, when I research something new, I hesitate to read descriptions of new things first. I’d rather search for video explanations or tutorials to get the summary of them before I read.

Even when I learn new programming languages or frameworks, watching video tutorials on YouTube helps me understand the basics much faster than reading documents at the beginner stage. The same goes for new users on your apps.

Even if you create decent descriptions and screenshots for your apps, they cannot win against video tutorials, which clearly show where you should tap and swipe with animations. There is a huge gap in usefulness between the two.

Making a good video is not easy

Having said that, it takes time to make a decent movie, especially if you want to make a really nice and professional video.

You should care a great deal about scripts, sounds, and editing. These things can cost a lot and take up a lot your time.

That’s why I didn’t place much of a priority on making promotional and tutorial videos, especially as an indie developer who didn’t have enough of a budget.

For example, you will see many high quality movies for apps like this on the web.

Making a video like this must have been expensive, and I certainly can’t afford it.

If you are running a startup, a video has an important role when you do fund raisings. For me, it’s enough if users can understand what it is.

For new users, I wanted to create a video that shows the experience they can get from the app, instead of just explaining how to use it.

Creating a video that demonstrates the user experience

It’s hard to make a video that really demonstrates the user experience. You certainly can’t make a good one within a few hours.

I made just such a video for my app Voicepaper.

It’s not quite as nice as the path video, but I guess it’s ok, considering I recorded it with my iPad. Thinking about scripts, recording, and editing with iMovie still took a lot of time.

If making a detailed video takes up too much your time and it’s not an easy task, I would prioritize and do other important tasks first.

Regarding the Voicepaper video, I still don’t know if making it was worth my time or not. Measuring the cost-performance precisely also doesn’t seem to be worth the time.

I was very lucky, just like getting a gift from Santa Claus. My competitor made my app promo video for free, but that kind of thing doesn’t usually happen.

Recording simple app usage tips is another option

The thing is, I thought making videos was not cost-effective enough before, but I was wrong.

From a developer’s point of view, I’ve always wanted to create very good ones, which doesn’t make my apps cheap.

But from the user’s point of view, they just want to decide if an app is worth downloading by looking at a quick video explanation.

Especially if you make tool apps like I do, users know what your apps are made for from the start. Therefore, showing them some basics on how to use the app could be enough.

You can also explain the benefits of your app briefly at the beginning of the video.

I realized this when I was learning a new programming language on YouTube.

You can learn quickly from documents or blog articles once you know the basics and backgrounds, but at the beginner level, watching easy tutorials is very effective and fast.

For example, if you are interested in making iPhone apps, here it is.

This is a video with only screen and voice, but it contains very detailed information that simple text with screenshots cannot cover. You don’t need fancy sounds, actors, and the camera even has shake correction.

This is it, I thought. Why I didn’t use this format before?

It doesn’t take very much of my time, probably only a few hours, including editing with iMovie. The cost of making it is very low, but it still makes a huge difference.

When I get questions from users, I try to explain how to use my apps in details without any technical jargon, which can be difficult. If I make a tutorial video once, the support process becomes easier since I can now just show the video and give brief explanations when needed.

I made one video in less than 3 hours

I started recording the usage of my bookkeeping app Taxnote.

0:10~ Basic Entry
0:55~ Add memos
1:15~ Editting entries
1:30~ Overview for entries
3:00~ Reorder categories
3:10~ Rename categories
4:15~ Bulk delete
4:33~ Data export
5:25~ Print your data
6:20~ About upgrading

English is not my native language and I don’t speak it fluently, but I can still show where to tap, swipe, and explain basic uses with my left hand.

All I did was record my explanations one by one with iPad, and then edit them with iMovie.

Speaking of editing, I merged several clips (4-5 minutes each) and added subtitles. In the end, I increased the speed of the video to 140% for users to watch it faster.

It’s that easy. It didn’t even take me 3 hours to finish.

I put this video on the top of the Help page with the table of the contents.

I always try to think of ways to get good results with a minimum amount of time, and this video tutorial is something I should have done earlier.

I made a redicuralsy simple timer app.

I made it since I had wanted the app like this for a long. It’s free, search for “ListTimer” on the App Store.

Download ListTimer Here.

※The language of the video is Japanese, but the app supports English too.

This is the simplest app I have ever made, but I created it because I personally want to use it.

Why did I make an another timer app?

I use the default iOS timer app very often, almost everyday. For example, I use it for setting my work time.

In this case, it’s ok to set 3 or 4 hours one time a day. However, if I want to set 3 or 5 minute timer quickly when I cook or do something, it’s a pain.

First, the tapping area on iOS timer app is very small, and you need to select your desired time carefully using that hard-to-use drum roll UI.

I have many situations in which I want to set a timer, but to keep using the iOS default timer app makes me tired everyday, and I wanted to fix it.

How about other timer apps available on the Store?

OK, I tried lots of timer apps available on the App Store myself first. I thought I could find the one suits me easily.

I was wrong, I could find nice apps which have lots of features, or looks cool, and are customizable in different ways. But, All I wanted was a simple app where I can set times very easily and keep using in the long run.

I needed a timer app focused on the part of setting times and starting it quick.

So, I researched on timer apps available, and how I can improve it to make the one I love to use very often.

In the end, I found the easiest way to set times is setting the time list from 1 min to 90 min from the first, and scroll it to start one of them with one-tap.

Every list height should be big enough to tap it comfortable, cool, this suits me best! This is great, simple is best, less is more! I don’t need the other features!

I showed it to my friend, and he said “You can’t set 1:30?”, but I answered calmly just like a king, “This app doesn’t need that, that is because I don’t need it”.

Honestly, I thought I might need to make it possible to customize times, but I can think about it later if this app becomes popular enough.

Background behavior

One problem, third-party apps cannot play audio like iOS default timer app does. This is the same for all third-party timer apps.

I enable Silent mode almost always so this is the most important part for me. If you disable Silent mode, it plays audio with notifications in the background though.

Therefore, this app sends several local notifications in a row to let you know the timer is done.

Local notifications vibrate your device even in the silent mode and background status.

By the way, it doesn’t consume battery power since it schedules a timer locally. It also works offline.

About App Store Descriptions

I like to try new things as much as possible for learning. This time, I have done a different approach on the App Store. Instead of writing the app description normal way, I wrote why I made this app over there.

It could be less boring rather than listing features one by one, oh, wait, this app doesn’t have enough features to list anyway.

I was worried about being rejected from the Apple reviewing process as claiming it as a too simple app, but maybe the reviewer read the descriptions and understood the concept.

Please try it out if you are interested in using the fast one-tap timer app.

Download ListTimer on the App Store here.

It’s often said that you should listen to your users to improve your product. However, the reality is, it’s a really tough challenge, and I believe you need lots of practice and experience to do it well.

I still find it difficult to say NO to users, but I want to share my thoughts about this.

I feel bad about saying No to user requests

When I was watching the iPhone5s Apple video, Jonathan Ive said something like this.

We are as proud of the things we have said No to as the things we have done.

I believe this is really important thing for product design.

When your users request or suggest some ideas, usually, every one of them makes sense in their contexts, and I can understand why they want that in most cases.

However, if I execute every great idea, eventually, the product becomes messy one with lots of noises. It ends up being a product nobody wants by trying to make something everybody wants.

We should choose what to execute very carefully.

Having said that, even though I know the principle in my brain, when I get requests from users, it’s still hard to say No to them. Users like your product, and took their precious time to write something to you, but you have to say NO most of the times.

This is not easy.

When I read the 37 signals book “getting real”, I remember they say “It’s hard to say No, but you have to be good at it”.

As a Japanese person, we have a stereotype image about Americans that they are good at saying No. But, even if they think that is hard, for Japanese people who are really bad at it, it must be really tough challenge.

So, what can I do.

How do you reply?

So, how can I say No to users.

To people who took their time to give me feedbacks and requests, how can I reply? I always find it really hard.

For example, one person say like “I need this feature because..”, and you know that is useful, but you want to protect simplicity of your product.

Let’s say you explained like, “I understand the value of the feature, but I cannot make it since I need to add features which will be used for 80% of users at least.”

In this case, for users who requested the feature, it doesn’t matter if they are in the 80 % category or not, I might end up pissing them off by explaining to them with data.

I really want to say “I will do it in the near future!”, but making a promise about future plan is the last thing you want to do in product development.

You never know how your product goes, and you cannot avoid changing priorities of product often. If you make a promise, and turned out you couldn’t make it later, users would be upset.

Again, in the “getting real”, it is recommended to say “we’ll think about it” basically.

“Think about it”… this carried me back to my childhood when I was blaming Japanese politicians always saying “I’ll think about it” without promising anything. I now know why they needed to say in that way somehow.

Basically, I try not to promise anything to users, because I can never tell what I am going to do for my products in the future.

Even if I expect I would definitely implement one feature, I try not to say I am working on that.

However, I feel bad to say the same template sentences like a robot to users, so at least I try to understand why users request some features and explain my situations sometimes.

How do you say why?

It’s important to say “why” to understand the backgrounds of each requests well. Some people say we should repeat why, so we can dig into the needs behind the requests.

However, in the real world, it is easier said than done. Don’t you think you get tired if you are asked “why, why?” when you just request one feature?

In this case, I try to confirm reasons, just like, “you are requesting this feature, because you have this issue, am I right?”

I believe it’s less annoying to users instead of being asked with why, and of course, this attitude can minimize risks of implementing new features without knowing the real reasons behind feedbacks.

Priorities…

It sounds convincing when you say that “I cannot do that since I should protect simplicity of my product…”, but, it could not be a real reason for not doing something in many cases.

Sometimes, implementing some feature takes too much time, or I cannot see any corresponding benefit for the time. Especially when you are selling apps for a few dollars with one time purchase business model.

In this situation, it is much harder to explain this to users.

Having said that, it’s really worth listening to feedbacks from users as much as you can, since you can learn something you have never thought of. Even if you get opinions you expected, that means you are validating your hypothesis.

If you seek for feedbacks from nowhere, it’s gonna take a time to meet people which are your target users.

When they come to you and ask for something, this is a golden opportunity to learn a lot and get valuable insights.

Plus, you feel great when you see people who actually care about your product. This is why, I set a feedback box using Helpshift for Taxnote, Zeny, and other apps.

I understand you want to avoid getting support emails for apps when you stopped updating in the future, but, at least when you are working on that constantly, it’s worth putting a feedback box inside of your apps.

Related articles

This is a really good article related to this topic.
PRODUCT STRATEGY MEANS SAYING NO

“Avoid Setting Publicly Visible Deadlines” part of this article.
Running A Software Business On 5 Hours A Week

37 Signals Getting Real. One of the best in product development.
https://gettingreal.37signals.com/GR_arb.php

***
I got an email from Gergana of SANSMAGIC saying this issue resonated with her. Her book about how you can reply to customers includes very detailed tips on this topic, and she shares her own experiences in the real world.
http://sansmagi.cc/resources/