Building a product for yourself vs. for an imaginary user
Looking for viewpoints (especially with backed experience) on the pros and cons of building a product for yourself compared to performing user research and usability tests to build the same product for someone else.
I am only interested in building products for my own problems, but I'm trying to decide how much time and money to invest in building it for other small business owners instead of just myself.
I feel that I should focus on building it for myself as I can build a product that truly solves my problems (which I'm already aware are the problems of small business owners), but it feels backwards to go this route.
If you're building it to solve a problem you have, then build it for yourself. If you main motivation is to sell it to others, than you'll need to listen to their input at some point. Either way, get something built and modify it later.
A better way to phrase this might be:
Alone, you're an audience of one.
An imagined user is worse, because that could be an audience of none!
Best: find a group of people that share they same desires / struggles as you, make sure they'll pay for a solution, and build for them!
I'd agree with Paul - it depends whether you plan to sell your product or not. If it's just to solve something for you, that's fine. But if you think you may want to target other people in future, it may be wise to do some research as to whether what you're building will be suitable for them too.
As it happens, I'm currently working on two products taking different approaches. One we built to solve a problem we had then decided to market and sell it half way through the development. If you're interested, read about it here: https://yack.net/2017/11/07/accidental-transcription-product/
The second product will also be used by us, but it's always intended to solve problems other SMEs have, and to be a launched product which makes money. I guess you'd say it was an intentional product.
While the first one has arguably been easier to develop (we know with more certainty what the requirements are!), I'm expecting the second to be the more successful product, because we're done it the 'right' way.
Hi Chris!
I started building a startup to solve my own pain with time unwillingly spent on different bull*it instead of work, but we quickly scaled up to listening of what our users have to say even on a validation phase. From experience, the best approach is to combine both ways.
The feedback channel is a must, but you'll need to learn to filter it by the level of importance and relevancy.
I'd say, listen to your customers in a first place, but make decisions based on your own vision of the product and what you can allow to be implemented considering your resources.
If you are solving a problem for yourself, you might be solving it for others. Start there, build what you need to solve "your" problem without building too much customization in it. Stay lean, ship it out and spread the word about it, the rest will fall into place if it's meant to be.
I like this approach.
Couldn't agree more. Assuming is a basic flaw , better solve one person's problem , your !
I wrote about it also previously ,https://medium.com/@shakks/validating-a-idea-without-user-feedback-c231a485d41
You definitely shouldn't build for an imaginary user, but that doesn't mean you have to build for yourself.
Hopefully, the product you're building is just your attempt to solve a serious, quantified problem for somebody. It doesn't matter whether you are that somebody or not, but if you aren't then you need to be careful to spend enough time really understanding the problem you are solving (by talking to potential customers and trying to sell to them).
The easiest route is to build for yourself.
The second easiest route is build for someone who is very into solving the problem and willing to work with you. Hopefully willing to pay for the solution as well. This happens quite often in the line of freelance work.