Stop Wasting Time and Start Measuring Before Building
Stop blindly building.
Product Managers, Developers and IT need to know what’s actually wrong before starting a project.
Often times I get hired for the same type of technical projects. Infrastructure upgrades, cloud migrations, mobile projects. These can be very complicated.
After doing the same project a few times, you can go from working in Agile to using Waterfall. Eventually with repetition, deploying that new platform becomes as straightforward as setting up an email server.
Partaking in these lengthy projects, one has to ask “why are we doing this?”.
This question typically isn’t asked when people start a new project. When I ask, the usual answers range from “management asked for it” to “our current solution isn’t good enough”. What I’ve learned to ask after hearing these responses is “says who?”
Scared employees then respond back “do want speak to the CIO and ask?”, to which I respond “Yes, I do actually want to speak the to CIO”. Fear is too often the reason for blindly following directives. This points to a major culture issue which exists sadly in startups and big companies a like.
Projects driven by interpreting what management wants are typically disasters. Instead of actually speaking to the CIO, COO or CEO, people just play broken telephone. We spend too much time trying to interpret what management said and working off other people’s opinions. Eventually we get so far away from our original goal that we deliver something entirely different than intended.
Even worse, management themselves work off assumptions. These assumptions are based on gut feelings, what their competitors are doing or what the industry is moving towards. Executives also are working off of a small portion of the larger picture. This is because they’re often lied to so people can save face.
All of these time consuming guessing games lead to lost money and unhappy users. Don’t assume employees will be happy with wasting time just because they’re getting paid. People want to feel like their work matters.
How many times have we heard of some “stealth startup”, that raised a few million dollars and is launching some “revolutionary” product? What happens is the product launches and nobody wants it. The company ends up imploding because they spent two years working on a product that was built using misinformed assumptions.
Over the years startups have learned how to quickly test their ideas, measure results and then refine their original ideas. This is called the Lean Startup methodology.
The problem with this approach is that it is still wastes a ton of time. Sure a team of men can run a small experiment to try and figure out what their women customers want. This experiment will cost thousands of dollars even if it’s ran using an Agile approach. Instead, they could simply just interview their customers instead of blindly building.
Lean methodology has become an excuse to build products that nobody wants and then scrapping them half way through the project. Stop experimenting. Start asking your users questions. Start doing user studies.
User research is critical to the success of all technical projects, especially for developers, product managers and IT.
Be warned, there is another pitfall to avoid.
In one of his last public appearances (2010), Steve Jobs was asked a question about how to sync a large iTunes library to other Apple devices. True to character, Steve promptly corrected the questioner and responded “no, what you’d like to do is share of media amongst your various devices”.
This was years before any such features were existed. Since, Apple launched features such as iTunes Match which lets you share your iTunes library amongst your devices and iCloud Drive for file storage. Sound like Steve knew the problem and had his own idea of the solution?
Steve’s solution fit with the greater goals of Apple’s vision. Apple now offers a music streaming service, an “all you can eat” newspaper subscription and a video streaming service. Of course, these can all be shared across devices.
This is why you do not want your customers solving your problems. It takes away from the cohesion of what you are working towards.
“If I had asked people what they wanted, they would have said faster horses” — Henry Ford
Collect as much useful data as you can. Try and read between the lines as to what issues your users are facing. Do not listen to their solutions.
The next time your users are clamouring for a new service, or a department wants a fancy new application, figure out why they’re asking in the first place. What are they trying to achieve?
Often you will find that migrating to a new email service isn’t necessary, you just need to resolve issues with your existing one. The same goes for launching new product features.
One marketing tech startup I worked for found that it would be better to launch an entirely new product and scrap the current one they had. This took months but they have grown exponentially since doing so.
The reason this company succeeded with a complete pivot is because they made an informed decision based on customer feedback. Yes they lost some customers in the process but they gained many new ones.
Many times I have worked with large companies who thought it would be a great idea to do a mobile refresh. This meant deploying a new management tool and buying new phones.
Eventually, we found out that employees do not trust IT and felt like they were being watch by “big brother”. As a result, these expensive phones with pricey monthly plans were just left in desk drawers.
What should have been done is a user survey and data analysis from existing services to see usage rates. We could have also checked our mail server to see if the phones are connecting (many did not). From there we could have concluded that we should focus on providing more services for users’ personal phones and building trust through education.
This is no different from the times I have worked for a startup where an executive requested a feature be built. Nobody questions the request because someone in a position of authority asks for it. Incredulous amounts of time are spent on development and in the end the feature flops.
Startups have gotten much better at quickly shipping minimum viable products and using that as a measuring stick. Still, if you spend even less time doing user research before developing something, you will find more times than not that you don’t need to build anything at all. Tweaks to existing products are often enough.
Pivoting from your initial position is a great thing, so long as you’re doing so based on data. Yes, there are some people like Steve Jobs who can move based on intuition alone. Your users and executives are not Steve Jobs.
Pickup the phone and speak to people. Run a user survey. Do measurements on your current product or service. Then make an informed decision about what you want to build next. This way when you go test out a new theory using a more agile approach, you won’t be completely shooting in the dark.
Your technical team will thank you.
Found this article interesting? Follow me (Kyron Baxter) on Medium. Check out my most popular articles below! Please 👏 this article to share it!
