A former community discussing the business of software, from the smallest shareware operation to Microsoft. A part of Joel on Software.
We're closed, folks!
Doug Nebeker ("Doug")
I have a problem with one of my apps where it performs a set of actions for the user behind the scenes, which is what they'll want; but if I explain to them exactly what it does, I'm worried it'll be revealing "trade secrets" as such and others can copy the concept.
On the other hand, if I don't tell the user exactly what's happening, will they believe my app is really doing all I promise, or will they think it's just snake oil (to paraphrase Wyatt)?
So, how much do you reveal the inner workings of your products to end users? Where is the line drawn? At the moment, if I don't reveal all, then any copycat apps may not do all that mine does, leaving my app superior. But if I spell out the features, they basically have a ready-made "ToDo" list for their copycat app...
As an analogy, think of CCleaner. The user can see all actions that it's going to perform, which makes copycat apps easy to do all those same cleaning functions. But it's probably no good for CCleaner just to tell its users "I'll clean your PC" without showing what it's doing, right?
You may not believe this, but 80%+ (my guess) of an app's success is the marketing, not the app itself. Inferior products make heaps of money all the time because their marketing is so much better than the competition's.
Most apps show all of their features. Sure, a copy cat can come along, but that copy cat has to be VERY dedicated to match your support, documentation, SEO work on your website, advertising via AdWords, etc, etc.
If I wanted to see what you app was doing, I could fire it up in any number of spy apps (ProcMon being the first one that comes to mind) and could reverse engineer it.
You're still focused waaaay too much on the code to be successful, my friend. The code is the easy part.
the OP said:
> As an analogy, think of CCleaner. The user can see all actions that it's going to perform, which makes copycat apps easy to do all those same cleaning functions. But it's probably no good for CCleaner just to tell its users "I'll clean your PC" without showing what it's doing, right?
I'm not sure, but isn't CCleaner insanely successful? Apparently telling what you do doesn't prevent massive success. Did they capture 100.0% of potential customers--or did they lose a few to copycats? I don't know. My guess is they aren't really focusing on that, understandably.
Then Doug said:
> You're still focused waaaay too much on the code to be successful, my friend. The code is the easy part.
I just have to pop up and say maybe that's true for some people and not so true for others. For me, the coding is the hard part, I think, though I haven't gotten to the marketing part. I can't imagine how it is going to be even 5% as hard as the coding has been. (If it is actually harder, I will regret having gone down this road at all.)
How much to reveal depends on what your app is doing and who its targeted at. Take CCleaner, you know what it's doing, atleast what its reporting it does but do you know exactly how it does it. For a typical user of CCleaner they may just want to know how it works as far as "it goes through and removes unwanted stuff off my computer." Even knowing the exact steps how long will it take a user to do it manually and how easy will it be. I routinely get asked by users how something work or what is a plugin is doing. My question to them is how detailed do they want me to answer it. Every seemingly simple task that can be made easier with an application is because the details of a task is actually much more complex or intricate then it seems.
Spelling out the steps doesn't always make it easier to clone. For years the steps that CCleaner does was posted on various sites and forums. CCleaner merely too all the steps and put it in one program to do it for you. Then added features to those steps to give it more value. I think the biggest thing it did was get the marketing right so it's one of the first apps people think of and fine when looking for that solution. There's lots of other apps to do the same thing now but they may not be doing it the same way or with the same quality.
Contrived example: App copies files from users computer to server directory for use by other automated processes. Usually done by hand by users. High level overview the apps looks in a specific local directory and copies the files to specific server folder based on file names. Usually that's all people want to know. It's enough to know what its doing but not enough to exactly clone to same level of quality.
Low level will be how to know what directory to copy from and to. How to parse the file names. What to do if the file exists already, etc... Thats the stuff that adds value that people who want to know what it's doing doesn't care about.
Friday, January 31, 2014
+1 to Doug.
Is your app already successful?
If not, then do everything that can make it successful (like telling your potential users what it does) and zero time worrying about someone copying it.
People only copy successful apps.
If you're already successful then retire to Barbados, which will remove all your anxieties related to running software business.
Also consider that if your app is so trivial that can be easily copied from textual description of what it does, then maybe it wasn't a viable long-term idea in the first place.
Friday, January 31, 2014
Also, #7 on this list: http://www.gamasutra.com/blogs/RobinHumphreyies/20140130/209719/Ten_Things_I_Wish_Id_Known_Before_Starting_Up.php
Friday, January 31, 2014
Based on the feedback above, I think I'll just be generic in my description and reveal basically what it does, but without the specifics. If another coder or company wants to use ProcMon to see exactly what's going on, then so be it; but there's no point in me just blindly giving the info away to those that don't know.
> if your app is so trivial that can be easily copied from textual description of what it does, then maybe it wasn't a viable long-term idea
The description does currently explain what the app will do, and therefore any one of you could make an app immediately based on that. But that doesn't make it non-viable, because for someone to do it manually requires a lot of work.
A Google search for "how do I <do my app's idea>" shows a LOT of website forums where people tell the newbie how to do it, step-by-step, which involves using RegEdit at one point (scary for newbies!), and even the annoyance of a reboot. My app removes all those steps and doesn't require a reboot, so it's a massive time-saver.
I think I need to remove the detailed description, because it's really there for people like us who like to know exactly what it's doing. Perhaps newbies don't need to see those specifics.
> I think I need to remove the detailed description, because it's really there for people like us who like to know exactly what it's doing. Perhaps newbies don't need to see those specifics.
Sounds like you should remove it, just as you say, because it is not good marketing copy in this case. Is it a developer's tool, or just for the average Joe or Jane Computer Owner? If the latter, you could say that gerbils are lifting weights inside the tower and they'd believe and be fine with that, as long as it did what they needed done.
It's not a dev tool, but it's for anyone who uses a PC at any skill level.
Anyway, I've removed it, which is kind of weird because now there's little to show what's going to happen... the user will just have to trust and believe that my app will do as it says. Before, I had a logfile which showed its actions, but as I said, that gives the game away for copycats, who might see features and think, "yeah, we should do that too."
"For me, the coding is the hard part, I think, though I haven't gotten to the marketing part. I can't imagine how it is going to be even 5% as hard as the coding has been. (If it is actually harder, I will regret having gone down this road at all.) "
Think of it this way: the hardest part is always the part you haven't done yet.
You finish a non trivial app and you think "sweet, I have done something" and it took you 3 months and it was tough and you made it.
But now you are going to spent the next few YEARS trying to sell the effing thing and it's going to make you wish you were back to that quaint stage when you were working on code with your well defined specs and knew exactly what the next step was and what problems you had to overcome.
+1000 for Krzysztof Kowalczyk. In spite of having a name whose pronunciation I can't possibly fathom, he is absolutely right:
Before someone can come in and steal your lunch, you need to have a lunch.
When your pocket is empty and you haven't eaten in a couple days, worrying about someone else eating your lunch is a bit premature. First you have to find food.
And lastly, I very recently realized that for me, the whole "worrying about copy" thing is an insecurity issue:
Inside I think "I am just an average developer, if that, not even a pro, I am just making this up as I go along and there is so much I don't know. Crap, I don't even know how to handle a threaded application and out there, there are tons of developers who know what they are doing and they can duplicate my work in an afternoon and..." and then you remember that apparently (even though it's hard to believe) a lot of the "pros" out there can't code a fizz buzz, much less reproduce an application from scratch.
These guys are no threat. And the guys who CAN copy your app in one afternoon usually work in well paid programming positions and couldn't care less for your two bits idea. They have other options, why would they steal your lunch when they can dine in 5 stars restaurants for free?
The only time you need to worry about these guys is when you make it to the point where they think "Gee, that guy eats better than me, I bet I could do that too". And by then, you are in a way better position than you are now, so why worry about what happens next?
Friday, January 31, 2014
Dificulty is more like
(Difficulty in marketing is not the seo tags, etc.. you put in on your website. Not the technical bits., its the whole marketing plan, marketing message and execution that takes time and effort to polish pull off correctly to be even a moderately small to mid sized mISV as far as sales go.)
Those of you who are at the coding stage, and have not bought a domain name, setup a website, a prototype screenshot with a lunch page, and a marketing / sales message to collect emails from interested customers, your already behind your competition, (who does not exist yet).
+3 to whoever said, shitty apps with a great marketing message have sold millions, while brilliant apps, with clean commented code, have fallen flat on their face.
Start your marketing early. and you will reap the rewards on launch day.
Start your marketing on launch day, and you will soon likely lose motivation and interest and your app will remain just a project folder with a bunch of files in it, and not a business.
Anyone here with a successful product, I'm sure would agree.
-1 if you disagree :)
> Before someone can come in and steal your lunch, you need to have a lunch
True, but if a schoolboy has a great sandwich lunch with a homemade sauce that the other kids really like, he can swap it them to get their lunches. But if some kid asks what the sauce is, and he foolishly tells then, then suddenly this other kid will start bringing their own version of that lunch to school to bargain and swap with others, and the poor original kid suddenly has nobody interested in him alone anymore.
As others have said, if someone is going to reverse engineer your product then they probably will and there is nothing you can do about it.
If your competitors are of average intelligence then can probably work out some of the possible techniques you are using without breaking out any tools to analyze your code.
What you should do, IMHO, is make an excellent implementation of your special technique. Describe it in just enough detail to sound clever but not enough detail so that you're giving your competitors confirmation about the exact method. Then in your marketing material you can call this method "SwabbleSearch TM" or whatever cool name you can come up with. You don't even have to register the trademark but if you do, registration is much cheaper than a patent.
In the rest of your literature you can start referring to your application as the "only product with SwabbleSearch" and making it sound like the only method worth using. Just make sure that it is a good technique otherwise you'll lose credibility.
Change your marketing copy to tell the reader about benefits, not features.
Unless your target market is techies, then they want to hear features.
Otherwise, details of how and what the software does is not of real interest to regular users.
They just want to know what problem your software solves, and what benefit it is to them.
Write it in a way that emphesises the benefits.
And yes, you went wayyyy to deep with the school boy analogy.
Before you worry about that, you have to sell 1000 sandwiches (licenses)
A copycat is always a step behind. Dont asume that if someone copies your product, they will succeed in marketing. Most likely no one will hear about their version of your product.
I've had people clone my website content even word by word, by copy paste :) hehehe. I contacted them and said, fu$k at least change the wording around a bit :). This in my case they did not actuly clone my desktop software. They made a variation as a webbased service, with 98% identical copy of text from my site :)
U know where his product is now?
The website graveyard.
Why? Because marketing is harder, than making or cloning a software.
I'm curious how that bingo card creator clone from that other guy on this forum is doing?
You are over valuing your IP. I think anyway.
If you are not, you would have thousands of sold licenses to prove me wrong. From what I've read so far, you are not quiet there yet. But it will come, if you stop worrying about trivial issues, and concentrate on spreading the word to anyone and everyoen you meet, online or offline. Even if you have to tell them how your software works, for them to be interested in paying for it.
How many sales have you had in the last 12months? and in the lifetime of the app? How long has it been on the market?
Or is it on the market? Are you keeping it from anyone seeing?
Are you not advertising so no one knows about your app so no one can steal it? :) I'm being a bit sarcastic, but thats the far end of the spectrum.
Some people prefer to play around with the code, for years, in fear of releasing, and being cloned, or copied, or replicated (ok they all mean the same thign). Or rejected, or not selling enough to justify the time spent on it. So they would just never know if the software is a success, and just keep at coding in their moms basement till the cows come home. But they live in the city, where there are no cows :) (not live ones anyway) Ok, I'm taking this too far. But I think you get my point.
-1 if you dont get my point :)
ON "THE CODING IS THE EASY PART":
> Think of it this way: the hardest part is always the part you haven't done yet.....You finish a non trivial app and you think "sweet, I have done something" and it took you 3 months and it was tough and you made it.
> But now you are going to spent the next few YEARS trying to sell the effing thing
Sorry, but this example exactly underscores my point: everyone's story is different. Yes, some people might take 3 months to write an app, in which case the development:marketing ratio is heavily weighted toward marketing. But what if you had been working on the app on and off for seven years prior to release? Then, chances are, the development:marketing ratio is much more weighted toward development.
> Dificulty is more like
> 10% CODE
> 90% Marketing
I hope and suspect your view is not always correct. Some people are just more effective at one or the other.
> +100 for saying marketing more difficult than coding.
Again, for some.
I haven't read it, but from what I understand about the book _Dreaming in Code_, the marketing was working really well--people were eager to get Chandler. The problem was in the development itself (indeed, the subtitle of the book is "Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software").
Yes, if you code a file renaming utility in three months, sure, then it's all about marketing. If your app has a lot of moving parts and a lot of things that can go wrong, a lot of care put into the GUI and the user experience, then I simply don't understand the mere assertion that "marketing is more difficult than coding."
> you can start referring to your application as the "only product with SwabbleSearch" and making it sound like the only method worth using
Oooh, I like this idea! That's an awesome marketing trick! Will be looking into doing that.
> Some people prefer to play around with the code, for years, in fear of releasing, and being cloned, or copied, or replicated
This app I'm doing is about 6 months of coding so far, but 99% ready for release. Just wanted to get your advice here about "do I reveal the method to all" first, and I have to finish the manual for it. I'm currently on leave from my day job for this entire month of Feb, so it's do-or-die time. If I don't release it this month when I have all the time in the world, then I probably never will.
Is your software so complicated that it needs a manual to use?
less than 5% of my users view my pdf manual or even goto the tutorials page.
My app is a fairly complex bit of software.
It would related to the complexity of something like coffeecup editor.
but not its not an html editor app :)
my app is geared towards none techie users.
I'm not saying you should not have a manual.
But you should launch now, and then work on a manual.
If all you have left is the manual, then you should launch today, and work on manual tomorrow.
Or does your product need more testing?
I'm curious if you'd be willing to share a link to your product site?
> Is your software so complicated that it needs a manual to use?
No, but to me, that's not a reason to exclude one with the product.
> I'm curious if you'd be willing to share a link to your product site?
Perhaps later. If it fails, no way. But if I get good sales, then yes, I will. :)
>> I'm curious if you'd be willing to share a link to your product site?
> Perhaps later. If it fails, no way. But if I get good sales, then yes, I will. :)
If your app's sales fail, sounds like the a great time to share the site and have people try to help you figure out how to improve it or do better in your next attempt, no?
>But what if you had been working on the app on and off for seven years prior to release?
I can't fathom why anyone would do that for a commercial product. The only way to know if a product will succeed is to release it. Why work on something for 7 years without knowing if it has any chance of success?
If you are an experienced developer, then the development is almost certainly going to be a lot easier than the marketing.
Programming is a hard problem, both in the sense of difficult and well defined.
Marketing is a soft problem. The things you have to do are relatively easy (compared to say debugging complex code) but you have to understand your customer and market (difficult), have an idea what starategies will work (difficult) and do lots of experimenting (time consuming). Also marketing is a zero sum game in that there is only a finite amount of attention in the world and you are competing for that attention with every other application in your market.
> Why work on something for 7 years without knowing if it has any chance of success?
Depends what it is. I personally have been using an app that I started writing 10 years ago. Yep, that long. It was NEVER intended for public release, but my wife and friends love it and keep telling me to sell it. My wife can't use our PC daily without it. However, to date, I'm just not interested in sharing it with the world. If I ever do, then that's one example that answers your question.
I did qualify by saying "for a commercial product".
> I can't fathom why anyone would do that for a commercial product. The only way to know if a product will succeed is to release it. Why work on something for 7 years without knowing if it has any chance of success?
Once I explain it, I think you'll fathom it well. In my case, I started from a dead start, zero programming experience unless you count BASIC and POKE statements from the Reagan (or in your case, Thatcher) era. So, the first good year of things I was just goofing around, really. (Which was a dumb waste of time). I had an idea for a program, but thought it would probably be released as a free and open source thing. I probably had something like "six month" in my mind as an estimate for how long a basic and working version would take to complete.
The following year I got into it more earnestly, and began learning and working. I have a job and a life, moved, etc., and other issues, so I was never working on it a large number of hours a week, and due to various things I would put it down for sometimes 1-3 months and then come back to it. Each year, though, I assumed "well I'm sure it will be done by the end of this year" and then I would find more bugs or issues that I had to attend to.
I was also working rather inefficiently, having no real training in proper technique, and learning by making a lot of rookie mistakes.
My app involves a number of 3rd party libraries, some of which themselves have some bugs or issues that delayed progress. It's also sort of three apps in one, in some sense, so there were disparate areas to deal with. I also was a stickler for the UX, so did some rather contrived things to get certain effects. Lastly, I wrote a lot of spaghetti code, so much of the time I am fighting myself to fix bugs, and have a very poor workstation to work on. Live and learn--if I did it over I bet it would go quite a bit faster, and this year I hope to transition to a more sensible approach, such as buying a better computer/monitor/desk, etc.
But it's still not done. The reason I would work on something for so long without releasing it is: it is still too broken. It would be like saying, "let's release this new car to the auto market even though we know if you take a turn at above 50 and this tight of curve you will flip it, but we'd better release it or how will we know if it has any chance of success?" The application, as is, is broken enough that it will be useless to most users and will turn off many, who would justifiably return it. But these bugs can be worked out and things improved such that those same people might be quite happy with it. And that's the plan.
Does that make more sense?
Missing proper equipment, bug ridden libraries, ux problems... It seems we have the exact some "blocks".
I now have proper equipment, I rewrote the libraries and ux can't be a real stopper for my app. Despite everything is now ready to support development I spent 3 hours this evening "playing" with a pet software project I'm the only user...
.... Probably my will is not strong enough, or I have lost interest... And I strongly feel these are not real stoppers
> Missing proper equipment, bug ridden libraries, ux problems... It seems we have the exact some "blocks". I now have proper equipment, I rewrote the libraries and ux can't be a real stopper for my app. Despite everything is now ready to support development I spent 3 hours this evening "playing" with a pet software project I'm the only user...
Thanks for the commiseration. How long have you been trying to write->finish->release->sell your software?
> .... Probably my will is not strong enough, or I have lost interest... And I strongly feel these are not real stoppers
Bah! Do it! Stay on target! :D
>Does that make more sense?
Yes. It is hard enough to produce a commercial product when you are an experienced developer and working on it full time. So doing it patrt time as an inexperienced developer must be very tough. But perhaps you should have 'cut your cloth' to fit and created something less ambitious? Perhaps just the most basic core of your current product.
BTW I am working on a new product part-time (PerfectTablePlan is my 'day job') and I hope to release v1 within approx 3 months of starting it.
Tuesday, February 04, 2014
> But perhaps you should have 'cut your cloth' to fit and created something less ambitious? Perhaps just the most basic core of your current product.
I quite probably should have done that, yes. When I started I had no good sense of how long (!) this would take me. I even asked online others' estimate of it, but I got no answers, unsurprisingly. It turned out to be a mixture of a quixotic and inefficient approach.
> BTW I am working on a new product part-time (PerfectTablePlan is my 'day job') and I hope to release v1 within approx 3 months of starting it.
How many lines of C++ code (I assume?) will it be in 3 months? Maybe that's the only metric of complexity I have to go by. In other words, what I wonder is how inefficient or pokey I really am. Should I expect to be writing 300 working, documented, and well-understood lines of code each hour I put in? Obviously this is meant mostly rhetorically...but then again, there should be a way to get *some* sense of whether your work output is on a "proper" trajectory, that is, accomplishment per time.
How long did PerfectTablePlan take you to write, from scratch to releasable? And then how much more beyond that stage? Was the genetic algorithm part of it a big time commitment? What *was* the most time-intensive part of it?
Thanks for your input!
>How long did PerfectTablePlan take you to write, from scratch to releasable?
v1 was probably equivalent to around 3 months of full time effort (I never really tracked it).
>And then how much more beyond that stage?
9 years and counting. Of course, a lot of that was marketing, support and admin. Not all programming.
>Was the genetic algorithm part of it a big time commitment?
No. It is a relatively small part of the overall package, in terms of LOC. But quite complex. I have recently substantially rewritten it to be a lot faster for really big events.
> What *was* the most time-intensive part of it?
Everything! Programming, documentation, website, support, marketing - they are all very time consuming.
Tuesday, February 04, 2014
>> How long did PerfectTablePlan take you to write, from scratch to releasable?
> v1 was probably equivalent to around 3 months of full time effort (I never really tracked it).
Huh. OK. I'm just trying to get a sense of the range here. Chandler, for example, apparently took 24 people working full time 3 years to release (those numbers could be off). If that's right, that's 24 x 36 months = 864 man months....vs. 3 man months for your project. Why were you "288 times" more productive?
I put quotes around 288 because these are not "real" numbers in any Objective Truth sense, but they do perhaps make the point: why do some projects drag on and on, *coding-wise*, and some don't, despite competent coders being involved in both cases?
Another way of looking at it: how can I make sure to be much more timely from start to release next time I take on a project?
At this point, it is quite hard for me to understand how you can go from nothing to a releasable product in 90 days. I'd like to understand that better.
The trick is to limit scope.
Andy wasn't 288 times more productive than Chandler developers.
What he released as v1 was 288 less complicated than what Chandler was after 3 years of work.
It's a common problem: people keep thinking that this feature or that improvement is absolutely essential for v1 and most of the time it isn't.
Even in this thread, PSB136 apparently thinks that having a manual is necessary before releasing a product. It isn't.
While he's working on the manual, he's missing all the feedback he could be getting from users actually using his software.
The trick is to understand what is the absolute minimum that is useful enough to be released and for most people it's much less than they think it is.
See also Lean Startup ideas e.g. http://theleanstartup.com/principles
Tuesday, February 04, 2014
> PSB136 apparently thinks that having a manual is necessary before releasing a product. It isn't.
Sorry, but I disagree. I've never downloaded an app that didn't have a manual, and quite frankly, if I did, I'd be shocked by the unprofessionalism of the author. I don't want that viewpoint of my products by potential buyers.
It may not be necessary, but it sure as hell isn't professional.
> While he's working on the manual, he's missing all the feedback he could be getting from users actually using his software.
Time is relative. Feedback starts when the app is release. If I release now, or in a month, it doesn't matter. The same feedback will occur no matter what the date is. :)
>Sorry, but I disagree. I've never downloaded an app that didn't have a manual, and quite frankly, if I did, I'd be shocked by the unprofessionalism of the author. I don't want that viewpoint of my products by potential buyers.
A lot of people never read manuals. Some people do; I am one and you are one too, but the people who don't care about a manual aren't going to judge your product by the manual (or lack of it).
I am amused by the subject line you chose. "Keeping your app secret". I thought, yeah, if he succeeds in keeping his app secret, that will solve all his problems. No piracy, no cloning, and nobody complaining that there is no manual. And no sales, of course.
> the people who don't care about a manual aren't going to judge your product by the manual (or lack of it)
And what about people who do care about a manual... they will surely judge my product by the lack of one. Plus I don't want to start getting support emails of, "Hey dude... where's your manual?".
You are really missing the point.
An unreleased app has 0 users and generates 0 revenues. This is where you are now.
An imperfect app will have less users than a perfect app but a perfect app doesn't exist. Your app will suck, just like all other apps. The only question is a degree of suckiness.
Now, I do write manuals for my software, so I'm not advocating not doing that but I'm pretty sure less than 10% users ever bother to open it up.
Your argument is that you would rather loose 100% of potential users by *not* shipping an app without a manual than loose 10% of potential users by shipping an app without a manual.
The math doesn't make sense to me.
The other point you're missing is this: your biggest problem is product/market fit.
Loosing 10% of users because of lack of manual or lack of feature X is not a problem. If the app is desirable then it means that you're making $9k/month instead of $10k/month.
A problem is when you make $0/month because no one needs the app in the first place.
And since no-one can predict if an app will be desirable, the only way to find out is to ship it and evolve it based on feedback (or scrap it if there's no interest).
To use a concrete example: today my SumatraPDF is downloaded about 20 thousand times a day.
When you look at its history (http://blog.kowalczyk.info/software/sumatrapdf/news.html) the first released version (0.1) couldn't do anything interesting and I'm pretty sure it didn't have a manual at the time.
And at the time the downloads were accordingly pitiful (few a month).
But I kept improving it, adding features etc. and I was able to prioritize my efforts based on user feedback as well as accrue SEO juice in Google.
I'm pretty sure the app wouldn't be as successful today if I e.g. waited additional 6 months because I *had* to have toolbar, or mouse-wheel scrolling or printing because what will people think about an app that doesn't have printing, right?
Tuesday, February 04, 2014
>At this point, it is quite hard for me to understand how you can go from nothing to a releasable product in 90 days. I'd like to understand that better.
As Krzysztof says, I restricted the scope. v1 was very restricted in scope. But it was enough to show that the idea had 'legs'. I also worked very logn hours. Having a mortgage to pay focusses your mind.
I cut some corners on the design to get the release out. I have since gone back and rewritten these bits.
Wednesday, February 05, 2014
Unless you have a lot of funds to back you up then anyone trying to enter the software business needs to go the MVP route. Arguably, even if you do have a lot of funds you should still go via MVP.
If your MVP needs a manual to be viable then your design is too complicated.
Do you have a website yet ? I mean fully developed with content and online, gathering views ?
Thanks, Andy. Even with just the basic sketch of the story (without all the gory details), I think I am putting together a better model of this now. Something like:
Solid developer background (Uni or self-taught, but well) + sensible design and structuring approach + limited scope + working very long days + mortgage = release of a MVP/v1 within ~90 days!
(And, the inverse: "rank beginner with badly cobbled together skills + no forethought or planning + too ambitious scope + dribbling in work as one feels like and sometimes getting put off for months, and thus losing momentum or forgetting what you were working on + working in too brief blocks + no mortgage and no massive need for extra $ = fail to release anything essentially ever)
I have a feeling there is a lesson here that transcends the Business of Software.
If there is no manual, then if I have a problem, what do I do? If I call for technical support, you have just increased your costs.
People can whine that if you need a manual, then the design is too complex, but that is not true. I have had too many times where decent documentation would have saved me a lot of time.
Wednesday, February 05, 2014
In the context of an MVP, if you need a manual then you don't have an MVP. I'm not saying that software in general shouldn't need manuals.
Furthermore, your earliest adopters will most likely be savvy about the type of software/terminology and need less hand holding than the average customer.
A data point (especially an imagined one) is no basis for making rational decisions.
I have an extremely popular (~20 thousand new users every day), fairly complicated app and I get few support requests per day at max.
My app is free but if you had those numbers with an app that you sells for $10, you would be many times a millionaire and hiring enough support people (or hiring writers to write manuals) would not be a problem.
We're talking about an app that has 0 users currently and will most likely have few downloads per day for a long time, because that's the reality for most apps.
37Signals has 15 million users and serve them with 43 people (http://37signals.com/)
Do the math on how much support time you'll need for 100 users, even if your app is so bad that it generates 100x more support than Basecamp.
Not to mention that it's better to make money and "pay" for customer support (where in this context "pay" means "spending some time answering e-mails from customers that have questions") than not to make money at all.
There's a big difference between saying:
a) If you launch an app without a manual, you'll be crushed by support
b) I launched an app without a manual and was crushed by support
If you said b), that would be a valuable factoid learned from experience, relevant to the topic at hand.
Alas, you said a).
Wednesday, February 05, 2014
> We're talking about an app that has 0 users currently
That's no excuse to slack off and release a half-finished product. And yes, the manual *is* part of the product. It's not meant to be a tacked-on afterthought. Well, maybe to other developers, but not to myself. I prefer to market a complete professional package from the get-go, because first impressions count.
I expect a manual with what I download, and so would a lot of others. To neglect it just because you don't know if anyone will use your app, is ridiculous. They might not be using it because of the mere fact a manual is missing -- it makes the product look cheap and nasty due to its omission.
Anyway, that's my viewpoint. :)
1) If there is no manual, I may have no way of solving any problem myself.
2) For some software, I like to sit down with the manual and read it. I hate learning by guess and by golly which is what is forced when there is no manual.
Thursday, February 06, 2014
I get the sense that people are arguing past each other about manuals. I mean, shouldn't the rule be "use your head"? If you write an essentially self-explanatory app that batch renames files and there are only four possible actions the user can take, and they are all very obvious and clearly indicated in the GUI, who would blame you for leaving off a manual?
If, though, you write a rather complex app with arguably some not-so-intuitive ways to use it, and lots of use complexity, then probably a manual is more warranted. You could deploy first and write the manual after six months and still keep some customers who enjoy solving puzzles, but I wouldn't blame Gene or PSB136 for asking for a refund on the app, either.
Software World is so different from real world products in which even rather simple devices like coffee makers simply never are sold without some kind of "manual". (In fact, manufacturers feel they have to include language like DON'T TOUCH THE HOT COIL, BECAUSE IT IS HOT AND COULD BURN YOU.).
This thread seems to be drifting away from the original question.
I think he wants to know. Should he reveal the "secret sauce", or should he hide it and risk being called a "snake oil" salesman.
I had to deal with the exact same question. I will share my experiences.
I was concerned like you about if I didn't reveal the methods, some people might claim snake oil, and also concerned of a competitor using our secret formula.
We decided to go with 100% transparency. We provide the user exact detail information to all of the methods, data, etc that was used in our software. They can pretty much see our exact formula.
Why? Because I believe it is the best thing for the customer. And the customer is my boss. I think the benefit of proving your software really does what it claims greatly outweighs the risk of a competitor having easier access to some of your key formulas.
There is a lot more that goes into building a successful software business than a few good formulas. I am not worried in any way shape or form that this puts us at any competitive disadvantage.
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz