Tag Archives: software

The Worst Product Meeting Ever

The title might be some hyperbole but a while ago I listened in on a product meeting that was eye opening in the sense that the bureaucracy explains why the product is in the state it is in after investing substantial amount of time in developing it. It was also a cautionary tale for every product and company I’m involved with going forward.

The meeting was a state of the union on the status of a project that had been in development for about a year but been talked about for a few. It also happened to be one that I think is the future of the business.

I pictured the product as having seven different sails all pointing in a different direction. Not making any progress anywhere but eventually one might get a big enough gust of wind that the only outcome will be capsizing.

This is a product that the high level management wants done so a lot of people are hitching their wagons to it. They hope it succeeds so they can get the feather in their cap but nobody is taking responsibility for its success. There is not a true, single project lead as everybody wants to have a say in every decision but the project is not the primary focus for anybody.

Without proper delegation nothing will get done.

The technical guys explained their choice of platform (there had been no discussion or due diligence done on this prior to development) not in terms of advantages but one which would result in the least amount of work for them when somebody wanted a report ran.

One person was not interested in what the product did only that they were able to harvest data from it for sales pitches.

It was very, very briefly acknowledged that in its current state there is no reason for anybody to use the product (one single user had logged in and used it in the lifetime of the product) but that was not deemed to be important enough for more discussion.

At no time were the actual needs of the users brought up.

As far as I can tell nobody ever asked, “What problem are we aiming to solve by building this product?”

I have no idea what the official takeaways were from the meeting. However some of my takeaways were:

  • Software is not a collection of features but a vision. Every decision that is made must contribute to and support that vision.
  • For users software is a tool used to achieve something. They do not care about any features that do not help them achieve their goal.
  • You cannot design a great product by committee. While many people may contribute, at the end of the day there needs to be a single, specific person who is the keeper of the vision and the arbitrator of all product decision.
  • When company leadership creates a product directive there are going to be many people trying to get the feather in their cap for moving it forward. Progress will drown in meetings and any that is made will be questioned and likely abandoned.
  • A meeting must have a specific, and written, agenda. When something comes up that isn’t on the agenda make a note of it and put it on the agenda for the next meeting.
  • A culture of open feedback is important. Every employee who touches the software or interacts with users is responsible for reporting bugs and passing on feature suggestions.
  • Always think of the user. If you cannot put yourself in their shoes with every decision then you’re going to lose them by creating something that does not address their needs.

There are many reasons a project can fail but if bureaucracy is unavoidable then it needs to be carefully managed otherwise an even worse fate can occur. That being a failed project that continues to consume resources as nobody will let it die.

“Software Eating the World” is about demographics

Software eating the world is about demographicsFive years ago Marc Andreessen wrote a famous essay titled, “Why Software is Eating the World.” In it he states that “More and more major businesses and industries are being run on software and delivered as online services—from movies to agriculture to national defense.” The reasoning behind that are that the cost of running servers is only getting cheaper and he gives plenty of examples of new companies disrupting the old guard.

What he doesn’t address in his essay is what I believe to be the largest driving force to his conclusion. Software eating the world is as much about demographics as it is about software innovation. Younger people more readily embrace software solutions and services.

Young people are technologically literate and already open up bank accounts, brokerage accounts, insurance, and purchase automobiles online without any face-to-face or phone interactions. They are comfortable with using computers to manage their money and, to a certain degree, computers managing their money (any financial firm that uses algorithms for asset allocation or order placement). They will likely retain that comfort throughout their life or, at least, until their wealth gets to be large enough that it would take more time and knowledge than they have to manage (e.g. setting up trusts).

The second reason that I believe demographics are causing software to disrupt many industries is that younger people tend to be more price sensitive due to their lower income levels. They are willing to trade individualized service for service powered by algorithms if it means saving money.

The final, and most speculative, of my reasons is that I feel that many young people place a higher value on their time than their parents did at that age. Whether they use that time productively or for entertainment they definitely do not appreciate wasting it.

What that means is that software will end up replacing service industries (though it could take a long, long time before it is true that anything a human can do a computer can do better). It is happening in the banking industry (Simple), wealth management (the many robo advisors), legal industry (LegalZoom), accounting and tax industry (TurboTax), human resources (Zenefits and Gusto), and the health industry (Fitbit is as much about the software as the band on your wrist).

Right now many people still trust humans more than computers. They want to get “a set of eyes on it” before sending off a report. That is totally understandable. I still hear people blame their computers/Outlook/Excel with their bosses nodding understandably. Younger people will more likely blame the user.

The people that still write checks at the grocery store might never embrace the software revolution. Supporting them will become a niche of every industry with high costs. Everybody else will eventually view services that requires a face-to-face or phone interaction as nuisances with the time being better spent elsewhere.

Four areas you can improve your workflows

Recently at work I’ve been pushing us to do something that none of us do often enough. That is to take a step back and examine the workflows that we go through every day without really thinking about them.

As your business changes, and the technology you use changes, there might be many things that you do currently that do not need to be done anymore, can be done differently and more efficiently, or can be automated.

Documenting workflows is the first step here and, as an added bonus, also the first step for establishing the standard operating procedures that your business should be creating anyway. So this exercise is one that should hopefully pay for itself many times over in the long run as your company grows.

These are four common places where your current workflows might need some work. It is in no way an exhaustive list as every business, and every individual that makes it up, has its own unique characteristics.

Death to the Stock Photo

You find yourself doing repetitive things in spreadsheets

When I first started my job at a financial services firm I spent the first week being shown the ropes. One of my jobs was to track all trades and make sure we got paid on them. This all happened in one big spreadsheet. Every day trade files were copied in followed by lots of sorting and copying and pasting data across many columns. Once a week commission files were received and were manually cross referenced to the spreadsheet.

I made the comment that a database would streamline this process and received the response, “Why don’t you wait until after your first week to make suggestions on how we do things?” (Lesson is that people rarely want to be told they are doing something inefficiently.)

As soon as I was done training and let loose I immediately built a database in Access that trimmed eight hours of work a week down to about eighty minutes. A couple of years later I developed a PHP/MySQL app that trimmed that eighty minutes a week down to about eight.

I love Excel and spend a lot of time in it but if you find yourself revisiting the same spreadsheet a lot, or do a lot of copying and pasting, then there might be better software for that task or a better system you can put in place to manage it.

You find yourself sharing documents via email

Email is great for communications but terrible for collaboration.I find email to be great for communication but terrible for collaboration. It is poor for collaboration for these reasons:

  • Two parties cannot work on a document simultaneously.
    • Once sent you have to wait for another party to send you their revisions before you can continue work on it.
  • Comments live separately from the document.
    • While most office software has the capability to include comments in practice nobody uses that. Instead they include their comments in the body of the email and reference the attachment.
  • Projects lose priority in an inbox
    • For better or worse many people still live their business lives in their inbox. While the project you are collaborating with somebody on might have priority over anything else subconsciously it is losing priority every time your collaborator receives an email that diverts their attention, (One of my big pet peeves is talking to somebody who gets distracted by the new email popup message.) They always read it to see if it is an emergency, maybe respond, but always take at least a few minutes to get their mind back into project mode.

We have just started sharing documents and gathering comments in Slack so it is a little too early to tell if it is a greatly better solution but I suspect it is for collaboration. Dropbox also just implemented comments on documents (I believe last week).

Personally I have found that I greatly prefer collaborating with people on files in Google Drive over files on a shared drive. Even then sometimes people make changes themselves or send comments back via email (less than optimal). Google Docs does has commenting built in that I just need to convince people to start using.

Whatever you are doing currently you should make sure that the software you are using to collaborate is something the compliments your workflow rather than trying to fit your workflow to software. (When all you have is a hammer you treat every problem as a nail.)

Great collaboration unleashes people and creates something that is more than the sum of its parts.

You find the data or documents you need exist in many different places

Most organizations have official ways of storing things. Many organizations also have unofficial ways of storing things as employees have found creative ways around bad software, decades old policies, and bureaucracy. That coupled with the explosion of SaaS in the workplace has companies having their data spread across many applications and servers.

  • Some documents for a project existing as attachments in emails, files on a shared drive, attachments to cards in Trello.
  • Feature requests and/or bug reports being put in both Trello and Github.
  • You have tasks in Outlook, in Asana, and on post-its on your monitor.
  • Multiple databases or web apps house your client data.

I have found that often Enterprise level software does a lot of jobs but it rarely is the best tool for each job. One great thing about the current generation of web apps is that you can often find and use the best tool for a job and it can communicate with your other tools via an API thus pulling all of your data into one place no matter where it is stored.

Tools such as Zapier or IFTTT can help you automatically get the data into the systems you need.

Startup Stock Photos

You need a system to keep track of all of your systems

If you are documenting all of your workflows and creating systems based on those then eventually you might reach what I’m referring to as protocol overload. At our company that is evidenced by having more tracking spreadsheets than you can count. Unless you are intimately involved with a process you might not know that a process already exists or where to find it documented.

Putting all of your systems in one, searchable, place is a great place to start. Excel documents that exist throughout a shared drive (and where you cannot search the contents across multiple files) is a terrible way to store protocols. Instead you could put them inside a company wiki, put them as different worksheets in the same Excel document, or, my favorite, create them all as templates in Asana so you can store the processes as well as implement them in the same place.

Every protocol or standard operation procedure should be periodically reviewed for steps that can be automated or are no longer needed.

Conclusion

Examining and optimizing workflows is a task that takes time but one that will be ultimately worth it. Eliminating busy work and increasing efficiencies will allow your organization to spend more resources on the projects that will continue to fuel your growth.

Excel Needs to Die

I love Excel.

We’ve been buddies since the Windows 3.1 days. It took me through school and well into my work life. I’ve strayed a few times and used Open Office (at home on my Linux desktop) and am finding I’m doing more of my personal projects in Google Drive but I still spend a great deal of my work day in Excel. I’m even still learning new features that save me time and headaches (I do not know how I just learned about repeating columns on pages when printing).

But I also hate Excel.

There is one particular use case that is getting my goat today. And that is using Excel for project management.

One of the things, if not the main thing, that has made Excel so popular is that it is so flexible. People use it for anything and everything they can fit into its grid format. Little or no thought is given as to whether or not it is the best tool for the job. And many people, including my office, use it to track projects.

Company map

I’ve got my department on Asana but many projects cross departmental boundaries. Every other department at the company uses Excel to track projects and we have dozens of spreadsheets for that purpose. Some of those are approaching a hundred columns. The workflow is thus:

1. New client comes on.
2. New rows get added to any project spreadsheets that are needed.
3. People need to remember to check spreadsheets for their tasks.
4. People complete their tasks, update the spreadsheets, and email others that their task is done.
5. People sometimes forget to email.
6. Balls are dropped. Tasks don’t get done.

The beauty of project management software is that you don’t need to manually notify others or remember to check files for tasks. The software does it for you magically! That cuts down on communications, and more importantly, errors. That leads to a happier and more efficient work environment.

Less email equals more smiles

With so much quality project management software being offered for free there is absolutely no reason to use Excel for that task. So I plead to you to make the world a better place and use Excel for what God intended it for. To store recipes.

(And if you want to replace the spreadsheets you use to track bills, client invoices, or time-off StartOpz has got you covered.)