You should build this if you want to build it. It's something you can point to and say "Look, I built something awesome!".
But, chances are this will not be able to make money as it (1) requires user setup (2) will be fairly difficult to build - api integration is not that easy (3) most users simply don't care about what happens to their data until it is gone.
(3, my experience) goes directly against your Thesis #2. (1) goes against your Thesis #3 - users generally are not forward thinking enough to do something now that will only benefit them later. I'd say start on actually trying to test your Thesis #1-#3 before assuming them correct.
I think this identifies the issues I was feeling with the product, primarily the point that users are rarely forward-thinking. Instead, they use the single service that is hot right now, and don't look for alternatives until their current one starts to die. The thought that they'd have to set up multiple services (some of which might require a subscription and others that require new accounts) will probably scare many off.
That said, I think an MVP is the way to go on something like this (NOT something fake with a fake button; that's for scammy money-grubbers). There is probably a niche for something like this; the only question is if they will pay for it or not, and pay enough to keep the service alive. I know of photographers that would love a one-click upload to all the photo sites. Same with videos, tweets, and blog posts. Seeing if they will pay will simply require you to try it.
2. Cross posting to multiple services is really, really hard. Each service has a different number of fields. You would have to get the user to complete the full information for each service in one go. Technically you could map all these fields, but from a UX point of view it's really hard.
3. Most services cross post between other services already. At least in a way that matters to most. And there are various ways that are "good enough"
Having said that, yes there is a demand for this. I've heard it direct from my customers. I actually work the other way in that I aggregate what you already post socially.
But I would look very hard at the financial side on this, I'm not sure you'll make enough money to warrant the effort.
2. Find the cheapest and fastest way to test whether potential customers think you should build it for them. For example, you could make a fake product web page with a "try free" button and count the number of people who click the button.
Asking us is not lean. Asking customers is not lean. Testing customers != asking them. Building it is too expensive a test to be lean.
Just because Lean is the buzzword of 2012 doesn't mean it's the right way to do it. This comment wouldn't have made sense two years ago, and probably won't make sense two years from now. Seems a little wrong to say that because it's not Lean, it's wrong. Let them find their own way, "wrong" or not.
Agreed. I can get behind the concept of MVP, but 'lean always' just doesn't have the evidence. Was Henry Ford 'lean'? IBM's big mainframe business... 'lean'? Were windmills 'lean'?
Nearly all big inventions are the opposite of lean - some people went and built something that nobody had thought of using before and those inventions took off. If you had just put up a survey asking people if they want a 'noisy, horseless carriage' you would have gotten a resounding no.
A lack of clicks on a random signup page with just a blurb doesn't imply the product will fail in the market. It could imply that users don't understand the value or a number of other things.
However, a MVP failing pretty much does imply failure, so I'd personally say throw out 'lean' and stick with MVP for anything 'pushing boundaries'.
I was just thinking the same thing, but it's a bit like kickstarter without the cash pledges. Which means all someone has to do to endorse your idea is click a button (potentially), which is no means an intent to buy the finished product.
Secondly I'd be pretty pissed if I put my idea up on a service like this, demand for it skyrockets, then someone steals it and develops it before me.
If you're going to ask visitors to answer questions, don't force them to read over things they don't need to know before getting to the meat of it. Just say "Here are some concepts for a _______ app/service, based on these screenshots, would you actively use this tool? If no, what features would you need to use it?"
That said, the response will be from so many different people with different ideas of their ideal solution to this that it shouldn't used to determine the worth. People will try something if it exists, and they'd rather waste their time trying to use it than answering questions about what it is.
(engineer * number of engineers) - (average monthly payment * number of customers) < 0
An engineer's salary at a small startup is at the very least $50,000, let's just round that down to $5,000 a month, so how long do you think it would take you to reach $15,000 a month in recurring revenue at what are probably $5 a month plans (this does not include any other costs such as office, servers etc). That's about 3,000 users. And that's just to pay a very poor salary with no other kind of expenses.
Nope, because you didn't believe in it enough to build it, instead choosing to waste time posting on websites. Zuckerberg didn't ask if he should build Facebook, the GitHub founders didn't ask if they should make GitHub, and Jason Fried didn't ask if he should build 37signals.
You're saying it's better to invest months of time, thousands of dollars only to find nobody wants it?
For every Facebook you quote me, I'll show you 10,000 others that didn't succeed and instead wasted time and effort when they could have done some customer research exactly like this.
that's not true. Not every product requires the same amount of "minimal".
You can quite easily get the signal from users of your MVP that they are not interested - when actually it's just that you have a crappy MVP.
Besides that, your original comment was not about building an MVP, it was referring to a full product. That's what I was referring to with "months" and "thousands"
That's some horrible selection bias. What about all the people who built something without asking anyone and it was a complete flop? What about all the successful products that did do market research?
How is a web form going to give you any useful data about demand? There's no investment or interaction with actual users. If you want to assess demand, make a minimum viable product.
I hope if you build it, you charge. I really don't think the world needs another remix of social for the average users. "Should" should be based on your needs (if you want to work for free, let me outsource some of my work to you), not whether or not the socialsphere needs it.
I think if there is value here, it is not so much in the backups and crossposting, both of which are available already. It would be in helping people manage their various personas or public image. And that would take something more than just tech tools.
I would use it and I know a ton of other people who would too. Is it the next industry dominating creation? No, but I believe any service built on the backs of other services hardly ever are. The product path isn't unique enough and in the end you always rely on another business for yours to do well. Blah... It would be a ton of fun to build though and you’d make a lot of people very happy to have it, which is really why we all do what we do. Official label suggestion from me: Hobby Side Project. Build the cortex and open it up to the community for tweaks.
"Further, the image file as well as its metadata would be backed up to your own little piece on the cloud"
Doesn't seem like much of a backup to me... I'd hope at the very least that even if there isn't a local storage option they would build it to support other peoples "cloud storage" products.
This is something we're debating. If suppose data was to sync with a folder on your Dropbox, we can't guarantee its integrity should you decide to remove or move it, whether accidentally or intentionally. This isn't unsolvable, but definitely something to think about.
Just a minor thing, but you should use smaller mockup images, because the automatic down-scaling is incredibly poor and results in a really jaggy image.
`width: x%` is always going to lead to poor image-scaling, but it can be mitigated somewhat.
This is very difficult question to answer. Unless you actually build it in some way and ask your target audience to use it you won't get any concrete feedback.
But, chances are this will not be able to make money as it (1) requires user setup (2) will be fairly difficult to build - api integration is not that easy (3) most users simply don't care about what happens to their data until it is gone.
(3, my experience) goes directly against your Thesis #2. (1) goes against your Thesis #3 - users generally are not forward thinking enough to do something now that will only benefit them later. I'd say start on actually trying to test your Thesis #1-#3 before assuming them correct.