7 "Must Answer" Questions For Your Product

This is part of an ongoing Series, “Joel Of All Trades”. It’s named after a little-known guy, Joel Spolsky, who has some kind of online journal or something.

In addition to the core functionality of your product (You know, the important bit like What It Does) there are a number of questions that must be answered.

For some Products, the answer might be a flat out NO, but they should all be at least considered.

These questions are vital for both Desktop and Web systems.

1. Registration

22012009125818am Can the User Register themselves with you?

This means asking yourself if you care about tracking Users. There are some situations where you might not want to, but I’d reckon most of the time you definitely want to be able to have some kind of User database.

Reason not the least of which is that you can strike up a conversation with the Users, on an individual level, given that your Registration functionality should capture their email address.

2. Activation (Trial/Full)

22012009125818am1 Does your Product need to be Activated?

If you’re selling a Product, you probably want some kind of Trial version. This helps the User figure out if they want it. Course, you could be awesomely popular and not have to worry.

For the rest of us Trial versions have to be Activated. And you should definitely have Internet (in addition to the User entering a code from an email) Activation.

3. Security

2201200915438amCan the User login to your Product?

The real question here is whether your Product is completely open, or not. If not, then you need User Login functionality.

A problem with having User login functionality is that it creates a sense of Security in the User. If they use a really simple password, this is bad.

Making the User more aware of the need for a really secure password is paramount. You don’t want to force them (maybe), but you want to make it very clear (and not just when they create their password, but at regular intervals) that their password is lame.

4. Data Encryption

2201200915835am Do your data files need encrypting?

If your program contains any kind of sensitive information, you should be encrypting your data files. Even if not, you should consider doing so. Your Product is Your Product. Don’t give away anything you don’t have to (like structures and wotnot).

To protect data structures you obviously have to encrypt the entire file, as opposed to just certain sensitive fields. Really, if you have the ability, do the whole file. Can’t see any benefits for certain fields, unless it’s for human readability of the raw data.

5. Backup

2201200921111am Can the User back up their data?

This is a big deal. Giving the User smart backup options means less outlay for you at Support time. I’m not just talking about zipping up the data files when they press a button (not that there’s anything wrong with that, heh).

Backup and restore should be seamless. Corruptions will happen. So plan for the eventuality. Charge the User another $x/month for the Product to send backups periodically to your “Backup” servers. Ask the User if they’d like to backup at certain points. Find some external hardware backup options, or at least put up some Help articles (videos) on using other methods of backup.

Users will not backup on their own steam. That’s a general rule of thumb because it’s true for the majority. So take the ability to decide out of the User’s control. Or rather, give them one decision to make (like When is the program going to backup, or Would you like to send your backup’s to our secure off-site servers?).

6. Import / Export

2201200921218am Can the User Import/Export data?

Are your Users coming over from other Products? Would they have a big Excel spreadsheet chock full of data? Can they get their data out for further Services that your Product doesn’t provide?

When you start talking about Development APIs (which are all the rage with Web Services like Facebook, Twitter and FriendFeed) it’s really just giving this functionality in another form.

Put and Get.

7. Support

2201200922634am Really a no brainer. Every single Product should have some Support system. Whether it’s an email address or a big system (like Kayako), you need to Support your Product.

If for no reason other than to give a better understanding of how your Product works out in the wild. Users will always find ways to push your Product that you have never thought of. Just is.

With my new Product I’m using Get Satisfaction. It’s a web service, off-site (I’m not in charge of the data, or functionality). I’m trying it with this Product because the Product is small and I don’t have the time to put together a system with the same level of functionality.

I want my Users to be able to search for questions/answers other people have asked/given. I want them to be able to suggest new ideas for the Product. And I definitely want them to report issues.

8. Help

2201200923345am In addition to Support, do you have Help? Pressing F1 is pretty much ingrained into our consciousness.

So make good use of that pavlovian response. Start putting together a simple Help file. Screenshots and instructions. Having a good Documentation tool like Help & Manual or Dr Explain goes a long way.

But more, you can meld your Help together with Support, so that for a User finding the answer to a problem is done in the same place as getting instructions of doing a certain job.

 

Wow. That’s quite a number of important questions. It always amazes me how much I forget in the process of developing my own products.

Thanks for reading!

Which of the above Questions do you think have no relevance to your Product (and Why)?

What Does Fearlessness Have To Do With Anything?

16012009112550pm

Last night, amidst getting a new version of Oldaer out, I was inspired by Will Carling. We’ve been Twitter buddies for a couple of months now. He records his opinions, and sticks the videos up on the web (mostly at Rucku).

At about 10pm the fearlessness came  upon me. Doubt was nowhere to be seen. Pragmatism too was off on vacation.

It was half three at least before I fell asleep. And in that time I’d managed to:

Every project I start is potential. There are lessons to learn, processes to follow, disciplines to enact. And there is hope.

I don’t start a project thinking it’s going to fail. I don’t begin with my mind on all the problems. On reality.

I begin with fearlessness.

Do you have moments with this kind of fearlessness?

Code-Signing Your Own Exes/DLLs in SetupBuilder

In a discussion on the Skype Clarion channel just now, Wolfgang asked me to post how to Code-Sign your own Exes/DLLs in SetupBuilder.

Saddle up.

1. I’ve got my Certificate information in the “General Information” window.

codesign001 

Now I just want to sign my own files. Of which there are two. An EXE and a DLL.

2. So I go to the Script Editor.

codesign002 

3. Just above the “Features” line, get a couple of blank lines going on.

codesign003

I haven’t experimented past “just get it working”, so there are probably a bunch of different places you could do this.

4. Make sure the line is selected.

codesign004

5. Double-click on the “#embed Vista manifest…” Compiler Directive Script Function in the top right-hand corner of SB.

codesign005

6. As follows after the image:

codesign006 

(a) Add your filename.

(b) Fill out the Name and Description.

(c) Check these two.

7. Double-click on the “#code-sign application” Compiler Directive Script Function in the top right-hand corner of SB.

codesign007

8. As follows after the image:

 codesign008

(a) Add your filename.

(b) Put in a Description

(c) These should be defaulted, if you’ve got the same as me in 1.

(d) Definitely stick this in :)

(e) Check these two.

9. Compile

And there you have it. That’s all I did to get this working.

When you compile, the little “password” appear. SB will fill in the password if you’ve entered it. See (d) directly above.

Hope this has been helpful for Folk.

I’m Going To Run My Own Software Company

Welcome to the “Joel Of All Trades” series.

170920081464

Doing your own thing means that, in my experience, you have to be a Jack Of All Trades.

You come up with the idea for a piece of software. You do some design; database, UI. You write it. You use it.

Then the real work kicks in. You need web presence. Marketing. Relationships. You need a Support system. Bug and Feature tracking. An Alpha/Beta system.

You have to get a website. Make the decision about what to put on it. Screenshots. Features. Some kind of “look at me” frontpage. Images.

It’s a big job. And it’s not the end. Because, all of the before is only a foundation for the following:

You have to sell it.

This series, Joel Of All Trades will chronicle my own journey. A journey which begins with Oldaer.

The series name is in reference to Joel Spolsky, who inspires me every time I read his blog. Check out this post, The new Fog Creek office.

Oh, the Aliens in the picture above obviously have a very excellent plan for World Domination. They have Dragons. There’s a metaphor in that somewhere.