As anyone who has been associated with the undertaking of a new software project, we all want what’s best. As a CEO or CFO we want to see it in the bottom line. As designers, we want to create software that’s useful and pleasant. As developers, we want to write good code. As project managers we want things done on time and on budget. All of these things are good, but if we’re left in isolation, are we really focused on the original need of the software?
Creating good software has to be about more than our own skill set, no matter what that is. It has to be about solving the problem and making the most of an opportunity. To do that in the best way possible, everyone has to be together in a way that focuses on solving the original problem. In fact, every decision we make has to be judged in the context of the original project goals. While this is easy to say, it can only work if it’s more than just a philosophy. There has to be concrete processes in place. When thinking how we can build better software, here are a few uncommon things that can make a huge difference.
1. Create Real Customer Insight And Share It.
One thing I’ve seen in years of building software is that there are always disagreements on what to do but most of the time these disagreements are rooted in a disputed understanding of who you’re building the software for. I’m talking about the end user. The CEO knows best because they have the vision, the manager knows best because he’s closest to the action, the designer knows best because they empathize with the user, and the developer knows best because he sees the bug reports and feature requests and knows where things have gone astray in the past. The truth is everyone probably has valid points, but the only one who knows anything for sure is your actual user. The answer, talk to them.
At Slingshot, before we start any project, we evaluate who we’re building something for and then talk to those people. There are good and bad ways to do this, but that’s a whole separate topic of discussion. The point is that you need to know the problem your user is facing first hand, through their eyes, and you can only do this by traveling to their environment and talking to them. Let’s say you’ve done this, what it should look like in the end is clear notes of what those users are saying and the issues they are having in relation to your original project goals.
At Slingshot, we post the notes of our end-user interviews on a wall so we can always reference them when working through the project.
The great thing about this is that your team will notice trends, things that aren’t easily disputed by anyone. Things that can help resolve disputes and arguments about what the user really needs. In my experience, when these notes are created and shared with the entire project team, the number of disputes goes down dramatically and ultimately shifts to how best solve the problem instead of arguments about what the user wants and what the problem is. I think anyone would agree this is a positive shift and ultimately will result in a better product.
2. Use Product Managers. Not Project Managers.
First I want to state, I’m not knocking project managers, they play a valuable role. Secondly, I want to describe what I mean by these terms as they’re often misconstrued (I do not claim for my definition to be the end all be all).
A Product Manager is someone who manages the direction of a product, is typically strategic, and is always looking out for the end user and the problem the software is trying to solve. A product manager is sometimes involved in managing day to day tasks but its not typically their strong suit.
A Project Manager is someone who is mainly focused on the execution of a project as it’s laid out. Project Managers are great at following a process, keeping people organized, setting and managing expectations, and managing day to day tasks. However project management itself is not always strategic.
This is not to say there aren’t project managers who are also strategic or product managers who don’t excel at execution.
What I am trying to say is that before anything else a project has to have someone who is strategic and focused on the end user and original problem at all times. In my experience, a project usually starts with a high-level vision and is then handed off to a project manager immediately for execution. This is a huge mistake as there are hundreds of decisions that need to be made after an initial vision but before or as part of the execution stage. These decisions cannot be made in terms of scope and budget, they have to be made in the context of is the original problem being solved in the absolute best way possible. There has to be room for understanding the user, experimentation, change in direction, and even sometimes a decision to kill the project. If room is not made for any of these, then a project can be built in a way that doesn’t solve the original problem and fails to be adopted.
3. Mix Your Teams.
Everyone sees things through a different lens. When we’re talking software, designers, developers, business managers, project managers, product managers, and C suite executives can have dramatically different perspectives. All of these roles have something to offer to the success of a project. In most cases, these roles cross paths at some point, but usually not for collaboration on key decisions.
Usually it’s a one after the other passing of the baton and opportunity for collaboration and shared discussion is lost.
To do better, developers, designers, and product managers should hear about goals directly from the champion of the project and hear customer insight directly from the end user or at least directly from the team who is carrying out customer research. Ideally, all members of the project team should hear these types of things before key decisions have been made.
By hearing concerns and perspectives from different areas early, better decisions almost always result.
Summary
Creating software is a huge investment and doing it better can make magnitudes of difference to the bottom line and people using it. To be better, software has to be evaluated on how well it solved the original problem and/or took advantage of the original opportunity.
Because there are endless options on how to build software, it matters greatly that key decision points are made based on real customer insight, product managers or someone carrying the strategic goals with them at all times is intimately and constantly involved, and that teams are mixed to get valuable insight from all areas.
