As an independent consultant that works both in and on my business all day, every day, I’m always on the lookout for new software and services that can help me stay organized, streamline my workflow, keep the constant ebb and flow of my seemingly never ending ToDo list under control, and capture the time I spend every day in a way that allows me to quantify the billable hours that I present to my clients as well as quantify the apparently massive amount of non-billable time I spend in front of this PC every day, day after day, week after week, and month after month. Some weeks I work 80 hours and only bill 20. Some weeks I bill 50 and only work 60. It all depends on whether I have billable or non-billable projects to do.

Either way, I want to be able to look back and know what I did yesterday. Believe me, without keeping track of projects, tasks, and time, I could work on something all morning and forget what I did by the afternoon.

So when new tools come around and present themselves to me in the form of a carefully crafted advertisement promising productivity nirvana, you bet I’ll go and check it out. Over the last couple of months, I’ve had the opportunity to experience the thrill of victory and the agony of defeat several times in my quest to find the ultimate time task and project management system, and one that I can afford. By afford, I mean afford even if times are super lean. Because times can be super lean in this business. When it rains, it pours, but when it doesn’t rain, you can die of thirst.

There were three SaaS offerings that got my attention and got me past the mythical “Pricing” page to actually trial the product. 17 Hats, Toggl, and TimeDoctor. There were several more that I checked out, but they were quickly dismissed due to either price or incredibly time-consuming learning curves. And the takeaway from all three of these packages is a common set of unfortunate discoveries that really became the impetus for me to write this article. All three of these software systems held a ton of promise (the thrill of victory) but fell far short of expectations (the agony of defeat). I came away from all three feeling that the people involved in the creation, development, sales, and marketing of these products actually don’t use their own product on a daily basis. I felt that not a lot of effort was put into defining the user experience, or the logical, intuitive ease-of-use necessary for a mass-market targeted software system. I don’t think these companies had a clue how actual in the trenches real world everyday users of their Great Software Idea  would expect to be able to use the software to make their lives easier and more productive. And training? I found the more complex and difficult to understand the UI and UX components of these systems, the more glaringly lacking the training components were. The takeaway, really, is none of these companies have a clue what kind of real training resources their users need because they obviously don’t have a clue how to use their own software. Because I guarantee you, 100% beyond any shadow of a doubt, if they had to use their own systems they would be a lot different. A lot different.

My organizational toolbox today consists of Gmail, Google Calendar, ToDoist (task management), Trello (project management), TimeCamp (time management), Quicken (home and business accounting), and SquareUp (invoicing, because Quicken doesn’t do electronic invoices). Gmail has tasks but no recurring tasks, so I have to use ToDoist. ToDoist is capable of tagging and categorizing my tasks, but once I check them off they disappear into the cloud somewhere so I can’t really see what I did at the end of the day. I use ToDoIst for reminders of things I do on a recurring basis. I have a ToDoist extension in Gmail so I can send an email directly to the task list (a much better solution than just “starring” the email. TimeCamp doesn’t interface with ToDoist so I manually start a task in TimeCamp and when I’m done I check it off in ToDoist. When the task is more complex than a single item in ToDoist, or if I have a series of tasks to perform that require notes, details, checklists, etc., I’ll use Trello. Trello interfaces with TimeCamp and I have a Trello Extension Chrome that allows me to start a timer right from within Trello on the card. But it allows me to start a timer when another timer is already running in TimeCamp, so I rarely use it. TimeCamp has an excellent and powerful Project/Task/SubTask hierarchy but doesn’t allow tying tasks and subtasks to multiple projects, so I have to create a “Web Development” task for every project that needs it. TimeCamp also doesn’t allow me to create Clients and assign a project to Multiple Clients, so I have to create a series of seemingly identical hierarchies – one for each client – so my TimeCamp project list looks similar to this:

  • ABC: Alpha Beta Capa Company
    • ABC – Client Communication
    • ABC – Web Development
    • ABC – Database Development
  • DEF: Dog Enemy Flag Company
    • DEF – Client Communication
    • DEF – Web Development
    • DEF – Database Development

When what I REALLY want is to say I worked on Database Development for client DEF and annotate each time entry with more detail about what I worked on.

TimeCamp has an Invoicing feature but the time entries for the week aren’t tied to a client, so you have to be very careful how you select the time entries for an invoice. That’s why I tag Database Development with the Client’s 3 character code. This way I make sure I’m not charging the client for something they shouldn’t be paying for. But since TimeCamp doesn’t interface with, I can’t use it. I won’t use PayPal as my processor because PayPal wants to keep my money in their system, then when I transfer it to my bank account it’s several days before I see it. Other payment processors charge more than, and they take a lot longer to get your money into your bank account. With SquareUp, if a client pays me before 8:00 PM today, the money is in my bank account the next day. SquareUp would be a complete solution for invoicing, but, they don’t allow fractional item amounts, so I can’t create line items like Web Development and charge 5.7 hours. So I create my invoices in Quicken, then I have to transfer the bottom line total of the invoice into a SquareUp receipt on a line item called “Total Invoice Amount”. This forces me to have to send two invoices to the client: a PDF printed from Quicken which has all of the aggregated time worked by line items like Web Development, Communication, General Consulting, etc. so the client knows what I’m charging for. They get a timesheet from TimeCamp with details about what I did that contributed to those aggregate amounts, and they get a SquareUp invoice that they can pay online.

Whew! And this is a very streamlined process for me compared to the way I used to do it. But can you see the real problem? The one just begging for a solution that nobody seems to be able to create? I need one software package that can handle emails, identify contact list entries as clients, allow me to create tasks and assign them to clients and projects, allow me to create projects and assign them to clients, allow me to keep a very easy to maintain timeline of work performed both billable and non-billable in one place and select permanent repetitively used items that are already tied to clients and their projects, or select task list items that are outstanding, create a vast array of robust reports, create invoices and interface with my payment processor of choice, and produce aggregate and detailed reports for the client that detail the work performed that coincides with the bill they just got.

Wouldn’t that be nice? So I’m always poking, prodding, and kicking the tires. The one piece of software that I thought might be the “holy grail” was But once again, like all of these other companies, they design their software around an idea not solving an actual real person’s real problems. 17hats doesn’t work with multiple users. Good luck growing your company and managing your employees time against projects being worked on by a team.

Failure Guarantee #1: Don’t force your entire company to use the software system you are selling

If you don’t force your entire company to use the software system you are selling, then your software will never be more than a great idea. It’ll never be great. I guarantee that if the developers at 17 Hats had to keep track of their time with their own software there would be a timeline view. As of last month when I finally gave up on it, there was no timeline view. There was no way for me to see all of the time I recorded for a day. I could create a report for a client for the time I recorded that day for that client, but nowhere in the software could I find a timeline where I could review my entire week, one day at a time, and make corrections and tweaks. There are many times when I’m working on one client’s software with a timer running and get a phone call from another client and have to switch gears. Many times I forget to switch to a new time task until I go back to what I was doing before. I need to be able to see my whole day in a timeline. I need to be able to sort the timeline view, change the start and stop times (or duration) of time entries, change the task (just in case I chose the wrong one and realize it later), split a time entry to make one big one into two (or more) shorter entries. The timeline view should be the heart of the system. And it would be if the company that attempts to create software in this niche used it themselves.

Failure Guarantee #2: Don’t define the user experience (UX) before a single line of code is written

I’ve made a lot of money in my career. Not as much as I’d like, but a lot more than many. I’d be lying if I said that a big chunk of the money I make is due to poor planning, or no planning. Not taking the time up front to work through and walk through scenarios of the user experience. That’s never my fault. That’s 100% of the time the fault of the client that’s trying to save on the cost of a project by not doing everything the right way. Planning, thorough testing, and documentation are always the hatchet targets of choice, and I’m fine with that. It’s job security. I get paid five times as much money to re-do something five times because it wasn’t clearly defined once.

It’s through this simple act of discovery and due diligence that you will uncover the real day-to-day challenges the users of your software will encounter and craft elegant solutions to handle them so the user never even knows a problem existed in the first place. Case in point: a data grid on a web page that doesn’t have a tab-order that mimics the way users will want to tab through the elements. Tab orders that jump around because the developer prefers to use his mouse and never uses the tab key to get around (see guarantee # 7). Entries on a grid that can’t be tabbed into and changed by setting the focus and typing. Lists that you can’t navigate with the up and down arrow keys on your keyboard. Items that should be editable on a grid view but aren’t, forcing the user to go and try to find where to edit it. Failing to make those places where you must go to edit easy to find. Forcing the user to spend a ton of time trying to figure out what to do. No screen tips. Popup forms that don’t set focus to the first field of the form, forcing the user to grab for their mouse to manually click into the text box they need to use. Not providing an experienced user the ability to turn off annoying tooltips that only tell them what they already know. Here’s a good one: links that will take you to another web page (help links are one of the biggest offenders) causing you to lose your edits on a record. It goes on and on. These types of UX failures are really novice developer mistakes that I see all the time. If you talk about how the user experience should happen you’ll save a lot of money on project development.

Failure Guarantee #3: Don’t design the User Interface with total novices in mind

If there’s one thing that’s universally understood in the world of computers, it’s that Apple, Steve Jobs, and IOS got it right. They probably used five-year-olds to test the iPhone and iPad. There’s a reason why Apple people LOVE their devices so much: they have everything they need and nothing the developers wanted. It’s a simple equation. It’s one Microsoft could have and should have learned from a very, very long time ago. If they had, Office would be completely different. But it’s a gigantic bloated piece of “developer-ware” that only developers (and not even all developers) understand how to use. MS Office is a prime example of the 80/20 rule. 80% of the features and functionality are used by 20% of the users. 20% of the features and functionality are used by 80% of the users. But worse by far: 80% of the features and functionality are unknown to 80% of the users. 20% of the users know about that 80% of the software no one else knows. But… it gets worse. Out of those 20% of the users that are aware of the 80% of the software no one else knows exists, only 20% of those users even use those features. For every 1000 users of office, only 2.5 users actually use 80% of the software. So that begs the question: how did those features even get into Office in the first place?

Developers. Programmer Hubris. Project Managers that are Developers first and users second. It’s the developer’s need to conquer a problem they discovered that gives birth to this dizzying array of unused functionality. Macro’s are a good example. Show me a secretary that understands WTF to do with a macro. OK, out of a thousand secretaries that use office. 2 or 3 might use macros. That’s because they’re studying to be programmers at night. The problem with the solution to the problem the developer found? Nobody cares. Nobody wanted it. Nobody asked for it. The Microsoft Advisory Council is made up of Developers mostly, who have a very skewed “0.25 percenter” idea of what is needed in the software. In defense of Microsoft, they’ve been doing a really good job of putting the most commonly used features up front by utilizing the Ribbon, but still… Office could be way cheaper to buy if there weren’t an army of six-figure developers designing software nobody needs. Back to basics.

Your User Interface should be “kindergartner proof”. Plain and simple. Keep the complexity under the hood. Make it intuitive and easy for someone who’s never seen it before to just use it.

Failure Guarantee # 4: Create a really cool software idea without having any clue how anyone will actually use it

Here’s something all too common with tech startups and very dangerous to their health. Something that will doom the company before they open their doors for business. Something so dangerous that it puts the company, it’s employees, and their investors at risk if the doors do open. What could it be?

A great idea born of market research.

Yep. I said it. Creating a company around a great niche idea that is discovered through data mining marketing data is probably the single most stupid idea ever invented. Why? Well, that’s so simple you have to be severely impaired in your judgment not to see it. It’s right there. Right in front of you the whole time. What is it?

You don’t know what you’re doing.

Just because you discover that painting pinstripes on boat hulls while they’re in the water is a multi-million-dollar niche market that nobody is tapping into doesn’t mean you can start a company around it. Not unless you know how to paint pinstripes on boat hulls while they’re in the water. Just because everybody wants to learn about internet marketing, doesn’t mean you can start a company teaching internet marketing. Not unless you’re already an expert in internet marketing. Just because guys like me need and want a single solution for our time/task/project/communication/billing/accounting/invoicing and are willing to pay, doesn’t mean you should start a company providing that software. Not unless you’ve been in the trenches, working with multiple disparate tools and having to coordinate work with clients, employees, and contractors. But apparently that doesn’t seem to be one of the “laws of physics” in the Internet Startup world.

Because a lot of the software I’ve tested is actually software designed around a great idea by people who’ve never used or needed that software before. How else do you think a system like gets created? Whoever got the idea for this time tracker/project tracker/accounting/CRM/workflow automation monster must have been an accountant. I know this because there is this accounting module in there that takes up a lot of space. It’s useless and unnecessary. Nobody is going to give up Quicken or Quickbooks to use 17hats accounting module. It ties into your bank accounts. Why? What is it there for? Why does it exist? And why don’t they have the ability to have employees, managers and clients access the software? It’s a project manager that can’t support teams. There’s no way to aggregate and analyze time worked against budgets for teams of more than one person. In their own support system, they recommend sharing the username and password… WHAT? I really don’t think I want to give the username and password to the heart of the business to an employee when the Accounting is built in. Would you? This is a classic example of not have a clue how your users will want to use your “big idea”.

Failure Guarantee #5: Don’t provide enough or the right amount of training

If I have to submit a ticket to another support forum trolled by pontificating self-appointed internet police types, I’ll shoot myself. Literally. You can’t pretend that impossible to use software will be easier to use if users who don’t know how to use it are helping other users who don’t know how to use it. It’s a train wreck. I see it all the time. Somebody asks a hysterical question: “HELP! I CAN’T FIGURE OUT HOW TO DO THE MOST BASIC THING” and you get answers like “Well, I’ve never actually used the software before but it seems to me…”.

How many times have you seen “well, I’ve never used the software but” or “well, I’m not exactly sure how to start a video chat but maybe if you clear your cache”. Which brings me to another point. Clearing my cache is the absolute last thing I want to do. Now that every website in existence has jumped on the “double-opt-in” bandwagon, after I clear my cache I won’t be able to log in anywhere without getting a text message with a verification code. That’s always fun when you’re trying to log in to a website and you forgot your phone in the car and your wife took the car.

Telling users to clear their cache is not support. It’s stupidity. 99.9999999% of the time the cache has nothing to do with what the user is experiencing. It’s usually poorly designed software that assumes the user knows how it works under the hood and, therefore, knows what to do, when, and in the right order.

You need to have a very in-depth video library of how-to videos that not only explain what the buttons, input boxes, grids, and other elements do and how to use them, you have to provide really good real-world examples of how to use the various parts of the system in the context of how it will actually be used! It makes no sense to say: “This is the billing module. You select a client and some projects or tasks to create an invoice you can send”. No, not good enough. You need to provide examples. Use cases. Take the users through a complex set of integrated elements of your software. Microsoft makes this mistake all the time with their programming help. They’ll tell you the name of the function and the name and data types of the various parameters. But they don’t ever show you any real world scenarios of how to actually use the function.

Don’t be a dictionary that gives the definition and leaves out the example sentences.

Failure Guarantee #6: Assume your users have intimate knowledge of how your software works

I have to admit, that from the perspective of a software developer, this is probably the single-most difficult mistake to overcome. It is so easy to see how the user interface should be handled when you have intimate knowledge of the events, functions, objects, business rules, and data behind that interface. When you know that a field should only contain a number, you enter a number. You don’t enter text. So you don’t bother to write code to trap the error if somebody tries to type in a non-numeric character. Failure to properly anticipate and handle user errors is the cause of the vast majority of software crashes. The developer thinks “only an idiot would put text here”. So all of the software tests worked flawlessly. The software gets delivered, and users complain it’s crashing. Don’t be the guy who says “it works on my machine” because A:) it’s not happening on your machine and B:) you’re probably making more assumptions. When you assume users will somehow naturally and magically – through some form of osmosis – figure out what the purpose and intention of the individual fields, buttons, dropdowns and options are – your users will get frustrated and give up. I’m a software developer and this can happen to me using poorly designed software that assumes I know what the developer knows.

Once again, you must design the software so your five-year-old or your 80-year-old grandmother can figure it out, and you have to make it easy enough for them to find out the answers to the kinds of questions they’ll naturally have as they move through the software for the first time. The best software has tooltips, help buttons that open popups with more detailed descriptions of the fields, and even deeper help resources that open in new tabs or windows without disturbing the work of the users.

And don’t break the cardinal rule of design: never ever EVER require your users to know that if they change one option, they need to also change something else. I see this a lot on complicated settings forms for WordPress plugins. There will be a hundred options on a page, some of which don’t play well together. If this is the case, you need to control what the user can and cannot do so they simply won’t be able to make a set of selections that don’t work well together. Having some text in small type underneath a checkbox stating “if you check this option, then make sure you uncheck some other option” isn’t cool.

Failure Guarantee #7: Assume everyone has a touchscreen or prefers to use a mouse

I saved the best for last. This is one of my biggest pet peeves with software developers. The lack of attention to the tab order of elements on a windows form, web form, or grid. TimeCamp’s timeline is a good example. The fields flow from Notes to Duration to Start Time to End Time. When you’re in the Notes field, then, you would think hitting the Tab key will take you to the Duration field. Nope. Hitting the tab key on your keyboard will take you to the start time of the next record. When you’re in the Duration field, hitting tab should take you to the start time field, right? Wrong again. It takes you to the Notes field. The tab order on this form goes from the Start Time to the End Time then two fields back to the Duration then backward again to the Notes. I defy you to use this web form with your keyboard. It’s maddening. They are assuming I am going to use my mouse to go from field to field. This is the hallmark of a software development team that doesn’t even know what a tab order is. Not a developer – the whole team. It defies logic how this tab order can have existed back in March of 2015 and still exists today (November 2015). You know, the bugs people report that are – or should be – an embarrassment to your profession should get taken care of before anything else. I’ve reported the bug to them and it’s almost comical that it still works this way. I rarely reach for my mouse. I’m a keyboard-shortcut maniac. I expect the software developers who write the software that I use to run my business to know what a Tab Order is. Is it too much to ask? And finally, when you pop up a form (windows or web) that needs input make sure the following things happen: The first field on the form gets the cursor (focus) immediately. Don’t make me grab for my mouse to put the cursor in the field. That’s your job as the developer. Make sure the tab order works so I can tab from field to field and even to the OK and Cancel buttons. Make sure the ESC key on the keyboard works like hitting Cancel. And make sure the Enter key works like hitting OK. It’s just a standard that people who’ve been around a while expect.


When I started this article, I had no idea it would be this long. In fact, I was worried I wouldn’t have enough to say. But obviously there is a lot to say on this subject. So maybe I’ll write more articles about these individual ideas and really explore them. All I know is that the current generation of software developers are extremely talented young people with an incredible grasp on the advanced technology that goes into creating software today, but many of them lack the basic understanding of how real end users will use their ideas and creations. Many of them get a great idea one day based on an obvious lucrative niche market and run with it without doing everything they can to ensure that their software is written for the user, and not for their own egos (look what I can do) or enjoyment (look what I can do).