Software Business Challenge Part Two: Don’t Know What You’re Doing? Great!
This is the promised first update in my business software challenge series. It’s a collection of thoughts about why you need to document the process of building your software, even if you’re not sure where you’re going with it.
This series isn’t intended for web developers, coders or elite hackers. I’m a novice, and I’m also using, adapting and modifying existing code to build my program. (Legally of course.) I’ll also be hiring developers when I need to insert new features that I can’t handle myself.
I’m not at that point yet though. Let me tell you where I’m at, and what I’ve learned thus far.
Where Is My Software Challenge At This Moment?
So, my software challenge.
I don’t know how it’s going to work. I have a prototype with the most basic of functionality. This is going to be good enough to replace what I was using, but it’s nowhere near ready to be put into use for my business or anyone else’s.
Where Do I Go From Here?
I don’t know, but I’m writing all about it.
The development process is something you can write about and later publish on your software site. It’s natural content creation like I talked about in this article on thinking like a consumer.
The fact that you don’t know how your software is going to work is something you should write down as you discover it for yourself. Once you’ve learned how to use a piece of software, it’ll never be exciting to create a usage guide or explore the features, so notate the process while it’s new.
The list of features you want to add is obviously something you need to write about, discuss with yourself and research. These are all ideas that are going to create unique selling points for your business.
Creating a piece of marketing software? You’ll probably want to add in split-testing features.
Why? I don’t know, it’s your software… but you need to weigh up the pros and cons and see what your competitors are doing. Write all these reasons down, because you can put them straight into your sales letter later:
“We included split-testing because our competitors have it. However, we included X functionality and Y to make our service even better.”
Training Materials
I don’t know how my piece of software works. I’ll find bugs in the software.
This is all very important and must be documented for two reasons.
If you’re charging people for a service, be it software or otherwise, you need to give them training materials – or at least an idea of what they’re paying for.
Secondly, the training materials – when extended – might be a product all of their own.
An idea: You might be selling an app that lets people manage their time more efficiently. They pay $5 a month and you get a little leprechaun that emails them daily to make sure they’re on task.
You could create a one-time $10 book that goes through your method. Then, you catch the people who don’t want to pay monthly, and you’ll have an added incentive for the people who pay monthly, because they get the book for free. Obviously, this is their first two months of the software for basically nothing!
Future Features
There’ll be things that you want to include in your software at the outset which simply aren’t feasible.
That said you need to explore your options and write those things down, because if you don’t, you’ll probably forget them. Also, when you’re in the learning stage of your software and it’s all new to you, you’re going to be more enthusiastic. Writing down all the things you want to achieve is like bottling that enthusiasm and storing it for a later time.
Treat any product you create – whether it’s software or a course or anything new – like an enthusiastic yet unknowledgeable customer. This will help you draft all the training materials you need, and it’ll also help you find out where you can do better or add new options.
For example, my software currently looks ugly. As a person trying to create a piece of software that works, I don’t really care what it looks like. As a consumer, I’d be pretty disappointed if something I’d paid for looked terrible. At the moment, it’s looking like an application embedded on a plain white page in a browser. The fonts aren’t stylised and the buttons are just plain text.
This obviously exists a long way down the list of things that need to be sorted out for the program to be successful, but at the same time it’s one of the first things a customer will notice.
Final Thoughts
This update is a bit of a mix of thoughts and findings, and not particularly well-structured. However, I hope future updates will be more structured as the program itself – and my goals with it – also become more substantial.
Apologies to those of you who hate the stream-of-thought style. We’ll get there eventually though!