When I start working on Notecompanion, I don’t have a company or any obligations, so why would I do things like market research or a product/market fit?
My experience in the game industry has taught me that they are a hundred ways to go about implementing an idea, so even if something similar already exists, they surely don’t approach it the way I would.
Unfortunately, the lack of investigation would cost me much more than I had imagined. Getting to know if I have competition or not is both the most obvious and the least important piece of information I could get from doing my research.
Takeaway from this story
- The real impact of a lack of research prior to starting a new project
- Can the lack of research somehow be good for your project?
Read about my previous mistake
Mistake #2: no prior research
I hate doing research.
When I learn something new, no matter if it’s trading on the stock market or riding a long-board, I just go full in without looking back.
It’s only after smashing my face on the floor a few times that I go back and check some youtube videos about what I am doing wrong.
After all, getting answers before even trying is spoiling half the fun…
When it comes to Notecompanion, I didn’t even know that I was supposed to do any. I started the project without any obligation, just for myself, so why would I need to do any?
I also think that it is a programmer thing… you just want to do your own stuff.
Telling a programmer there's already a library to do X is like telling a songwriter there's already a song about love
— Pete Cordell (@petecordell) January 29, 2014
Putting the blinders on
During the first months of my work, everything goes perfectly fine. I am doing some steady progress with the app and the scale seems reasonable. I should be able to release by February 2017 like I planned.
My days are entirely focused on technicalities. I start my work by looking at my Features-To-Do list (which is conveniently hosted on the very app that I am developing) and start working on whatever is at the top.
If I find any bug during the day, I add it to my bugs-to-fix list and keep moving forward.
Working like this is almost relaxing. I don’t have to think about where I am going and just move from item to item. In theory, when the list is empty, my product is done!
This type of work is what I would call working with blinders. It’s perfect when you are in an organized structure, with a manager taking care of the long-term plan and a lead setting up priorities.
Unfortunately, it is deadly when working on your own.
The main reason why you don’t want to work this way is the feature creep. The behavior that very slowly adds to your workload. It’s not like a big batch of features gets added to your list in one day. Instead, it’s minor, micro features that get gently added, one at a time. Each of them is easy to deal with, but their sheer number makes your scope impossible to deal with.
I thought I was prepared to fight the feature creep because I had come up with a finished list of must-have features. I had a clear vision of what my app would look like and what was needed. Anything else would go on a “nice-to-have” list that I would only look at after release.
That’s where the first consequence of not doing research hit me.
When research is done for me
I hear about my competition from my friends who know what I am working on. Their messages usually go like that:
“Hey, have you seen this app that does exactly what you spent months working on?”
In another post, I will be talking about how to talk to someone trying to make it happen… just a hint: “You are wasting your time, you should change everything” is bad, “How can we make it work?” is good.
Of course, I have some basic knowledge of what my competition does, but I never took the time to analyze them in detail. Back when I started, I had no reason to: I was only doing this app for myself. Now that I have bigger plans for my app, I still don’t see the point. I will be done with it in maximum two months so I will figure all of this out after I release.
Thinking about it, maybe I would have been able to release my app sooner if I had never heard about my competition. With fewer features but also less time wasted.
Learning about a new competitor is always a strike to my morale. There is a world between when I start to work on something knowing that it has been done before, and when I discover about it when I am almost done with my own version.
Very few events can make me feel so much like I have been wasting my time.
The problem with this information is that you either change your plans or give up.
Of all the competitors I learn about, none is implementing the filtering feature I have in mind. So I think that it may still be worth it.
If I want to have even a chance of people looking at my app, I need to add the simplest features that all my competitors seem to have.
Obviously, I will only integrate the easiest points. Things like sharing notes with a link or displaying pictures, not the big stuff like document formatting, or file sharing.
And this is how the feature creep gets fed.
Feeding the creep
Because I didn’t study my competition before getting to work, I never got the chance to plan while taking all these small features into account. Instead, I add them without noticing how it impacts my plan.
With time I learn more and more about the other apps on the market, always from my friends.
Because my days are focused on technicalities, I completely lose track of my goals.
I slowly go from having to implement my competitors’ simplest features to having to implement original – but yet simple – ones, because without them ” it will never be good enough”.
To make it worst, this feeling is often accompanied by its best friend, the sunk costs fallacy.
In June, I am 4 months past my original deadline. What I was confident would be a simple, cool app to get started with is now devouring my budget.
My commitment to Notecompanion is nothing like what it was supposed to be. The app was meant to be a 2 months quick launch so that I can learn fast and move on.
The more time I spend on it, the more I start to expect as a return on investment.
I finally start to take the time to do my own research and realize that the demand for this type of app is way bigger on mobile than on desktop. It’s so obvious! Who the hell will use a note-taking app that is not on mobile?
If I don’t want all this work to go to waste, I know what my next step is: releasing a mobile version.
In this post, I say that if I had never heard of my competition, I would probably have released Notecompanion after 2 months. I don’t mean that you shouldn’t do any research and work with blinders. What I mean is that the results would definitely be below what my competition offers, but at least I would have been able to move on to the next thing.
With proper research, I would have known from the start what I was getting into. This would have helped me figure out what features are worth spending time on, compared to my competition, or if the whole app itself is worth the time.
I would have been able to look at my plans without the influence of the sunk cost fallacy and define what is really the core of my product.
In the next post, I will be talking specifically about how not having defined the core of my app stopped me from releasing an early version. Later, I will also approach the development of the mobile version which was handled by an agency in India.
I may have a quick section about how working alone has impacted my social life, as I think it is something to not neglect when working by yourself. It will probably be a delicate subject to get into as a number of people who are part of such social life read this blog 😉
Read the next post | Perfectionist to a fault: not knowing where to stop
If you want to get notified when a new post is published, subscribe below. There won’t be any spam. Only a mail notification when a new post is published.
8 Thoughts to “No research, bad scope: working with blinders”
Great post, once again. Little question, how much of this do you think applies to independent game developers ?
One of the games I am working on (and plan to get back on full time) is a text-based RPG simulating a tabletop RPG experience, except that the game master is an AI.
A major feature of the game is the fact that the AI procedurally generates a new story whenever you start a new game and adapts it to your action.
When I started to work on this game, there were not many talks of procedurally generated stories in video games.
However, as the development time to my first playable extended, games were released or announced, claiming to implement fully procedural stories.
The feeling I had when I discovered them is very similar to what I describe here. A hit to my morale along with the sensation that I have been doing it all for nothing.
I think that when this happens, you should either stop everything, cut features or stay on track. It’s important to not add to your workload.
It’s almost impossible that nobody else is doing what you do, and if you start adding features to stand out, you will probably never stop.
There are other things that come into play to determine if you are going to be successful or not. Focusing on them and getting your product/game out there should be the top priority.
But of course, it’s always better if you don’t have much competition to start with :).
Great post! I am looking forward to the social life section.
Another question: do you plan to write a bit more about feature creep and how you handle it? It is a bit tricky topic, especially if your plan isn’t just to “ship something”, so ignoring the competition does not sound like the solution to me. I see how it can be dangerous to keep adding new features as you go, but saying that I won’t add any sounds a bit meh – one might have better ideas during development. (Especially in games, with iterative design).
Ignoring the competition is definitely not the way to go. If anything should be taken from my story, it is that it can only be good to study your competition before getting to work on your own product.
However, as a solo developer, it can actually be better to ignore it once you are on track.
I believe the best solution is to have someone dedicated to scope management and competition research. This person would be able to look at the competition and decide if your own product has to adapt. If yes, then another aspect of your product would need to be cut/reduced so that the scope stay the same.
Unfortunately, it’s almost impossible to hold both hats when you work alone.
Even in a big team, one of the typical complaints that you will hear in the game industry is that “The game director played game X yesterday so now we have to change everything”. Everybody knows that this means missed deadlines and potential crunch.
Adapting to the competition on the fly, before the release of your product/game is probably one of the first sources of growth for the feature creep.
In the case that I develop here, I would have been way better off ignoring the competition and releasing my app after 2 months of work as it was planned. Once the app released, I would have been able to check the feedback from users and the competition and then set up proper priorities to improve it. Instead, I kept trying to keep up and totally lost track of the strength of my own product (and production time).
Another point is that it’s much more dangerous to focus on the competition when you don’t have unavoidable deadlines. At least the latest would be able to stop even the most perfectionist of developers from growing their scope ad infinitum.
“I won’t add any sounds a bit meh – one might have better ideas during development.”
Until you have the first version of your game/product out, I believe that new ideas should be done at the cost of others. You don’t have to be super strict about it, but it should be the general rule and not the exception. If you don’t put yourself in this mindset, you will easily grow a 1-year project into a 5-years one.
Another awesome post, Ryan. This topic in particular really resonates with me.
When I first started out as an engineer I absolutely took project planning and the role of a project/program manager for granted. Having someone else worry about the high-level stuff enabled me to quickly and easily get into a state of “flow” and just focus on my work, which I loved. Though the instant I started working on my own games, I’d start with a rough spec, but would then add more and more “cool” or “fun” features during development until I became totaly overwhelmed by scope. But at the same time, you can’t be expected to write a totally feature-complete, “perfect” product spec at the get-go that you follow to the T without responding to any user feedback or market forces. To be successful, room for flexibility needs to be part of the plan.
For me personally, the concept of the minimum viable product (MVP) helped immensely. By defining the bare minimum of I want in a product and then developing that prototype first, I end up with a “complete” version that I can do a limited release of and test end-to-end. This kicks off a cycle of getting feedback, speccing out the next version, and then sending out & testing the next version. Plus, if any version flops, I can scrap it without having invested too much time into it.
That being said, I work on web applications full-time so it’s relatively easy and cheap to get new apps/features in front of an audience for testing. As I start working on games, figuring out how to get frequent-enough feedback becomes a bigger question for me. Without dedicated playtesters, how can someone get incremental feedback during the dev cycle? Is there just an inherent risk of spending tons of time and money on a game/version that potentially isn’t fun?
Now that you’ve got the experience of working of Notecompanion under your belt, how do you think you’ll apply what you’ve learned about research and feature creep to your future game projects? Do you think it’s possible to implement incremental development principles to games?
Firstly, thanks for sharing your story :). When it comes to your questions:
“Is there just an inherent risk of spending tons of time and money on a game/version that potentially isn’t fun?”
Most games require a lot of content before having a first playable. And even the first playable is often too light for most players to enjoy. Working with apps makes it much easier to validate your idea with an audience and improve it as the user base grows. Even though I have released several game projects, I have no experience with releasing a game all on my own. This is one of the reasons I wanted to start with apps instead of games.
I considered that it would probably take me years to build any game I would be happy to release, with a very high risk of failure. The risk of failure is also high with apps, but at least I would be able to fail much faster with them, instead of burning all my savings (well, at least that was the plan).
I think early-access as shown how game development can profit from incremental feedback. However, it still feels to me that a game first playable require much more time and work than an app alpha.
What I learned with Notecompanion is definitely how to manage a scope. It taught me much about how being perfectionist is *not* a quality, and how striving for the perfect product can stop you from having any product at all. For my future game projects, my priority will always be to make sure that I have a core mechanic (and that the game is not just a lot of small cool ideas), develop it into a fully playable experience, and only from there consider what can be done around it.
It’s not so simple, but this is more or less the summary of my mindset. I could say much more about it, but I don’t want this comment to become a whole blog post in itself 🙂
Hey Ryan, your blogs are a great read, and I appreciate you sharing your experience going indie. I too wish to go indie one day and I am currently working on side projects while I work full time elsewhere. I look forward to hearing about your future developments and wish you the best of success coming up. : )
Thank you so much, Thomas. Best of luck with your projects – maybe one of them will be the one to propel you into the indie world 🙂