It’s the day before the release of your company’s hot new product, and you’re pumped. You’ve lined up a list of high-profile media outlets ready to report on the launch. Your client outreach plan is locked down. And you’ve got meetings lined up with potential investors every day for the next week.
Everything is good to go…until your lead developer emails to say that the user signup process is broken. Something about Facebook authorization, third-party cookies, and someone named Jay Sahn. To get it working, they’ll need to completely recode a third of the application.
You tell her that it’s the eleventh hour, and she absolutely has to have this fixed by tonight. But apparently the tech team has been working non-stop for the last 36 hours to implement several last-minute features, and she tells you that there’s no way they can do this in time. The only way to make the launch deadline is to drop the social network portion of the product, which is the entire hook for your media outreach and what sets you apart from your competitors.
In other words, you’re screwed.
Sadly, situations like these are not isolated events — they are common occurrences at both small startups and large corporations alike.
So, why do they happen?
The Technology Language Barrier
In nearly every case, these problems can be at least partially attributed to poor communication between those who are designing the product and the developers who are building it. If you’re in the former group, you might not have a background in technology yourself, and you rely on the development team to make your vision a reality. You have a meeting (or many meetings) with them to talk through how a new product or feature will work. But afterwards, you somehow end up on different pages, and the development process ends up being far more difficult than it should.
As someone who’s worked on both sides of this process, I’ve seen and experienced plenty of cases of this happening. It’s almost like each group is speaking a different language — and in some ways, they are.
Here are a few ways that product design staff and developers may be having trouble communicating:
Lack of Context
If your focus is product design, you’re likely connected much more closely to your users than the developers are. Because of this, you end up with a much better sense of how people interact with the product and what their needs are.
When describing the requirements for a new feature to the development team, there may be aspects of it that seem self-evident, based on your experiences with users. But the developers may not have that same level of intuitive awareness of how things should work, and based on a limited description, they may end up with a very different idea of what you’re asking for.
The result is development work that doesn’t actually solve the desired problem, and may lead to lost time or a sub-par user experience.
Perceived Difficulty vs. Actual Difficulty
This communication challenge is summed up well in the following xkcd comic:
When developing software, some things that may seem very easy to non-technical people can actually be very hard, and some things that seem hard can actually be quite simple. So when you describe product requirements to your development team, it may turn out that some minor features will actually end up taking a huge percentage of the time to build.
In a scenario with unlimited time for development, this wouldn’t be a problem. But you’re always going to be operating on some deadline, and time wasted on relatively unimportant aspects of the system could lead to delays or software bugs caused by fatigue or rushed coding.
Late-Stage Changes
As new products and features are developed, it’s common to realize part-way through the process that you want to add or adjust some aspect of the functionality. The difference from the original specifications may often seem quite small, so you might go to the development team and tell them you’d like them to modify the plan to instead build out an updated version with these changes.
However, the first step of any good development process is to scope out the underlying architecture for the new feature or product, and then begin coding based on that architectural plan. When part of the specification is updated, there’s a chance that the original architecture may no longer makes as much sense for the new design, even if the difference from the original specification seems quite small.
In those scenarios, the development team has the choice to either (a) start again from scratch, or (b) tweak the code to make the updated functionality work with the old architecture, regardless of it not being a good fit. Most development teams will opt for the second choice in order to save time. While this may seem like the smart choice at the moment, you ultimately end up with poorly designed code — which may cause your user signup process to break the day before you’re planning to launch.
How to Communicate Better
If you’re working in an organization that suffers from some (or all) of these communication challenges, don’t despair — there are ways to fix these problems.
As with any communication challenge, steps can be taken on both sides to improve things. Here are a few that can be done by product design staff to help overcome the language barrier.
Respect
When interacting with developers, make sure you do so in a way that shows you value their work. Don’t throw assignments at them without consideration for their existing workload, and make sure you’re communicating to them that their efforts are critical to the success of the organization. This requires very little effort on your part, but can make a huge difference in your ability to work together effectively.
If developers feel like you don’t respect them, it’s likely to poison everything else about the relationship. In contrast, if they feel like you value their contribution, they’re more likely to put in extra effort to communicate challenges and get work done on time.
Not just What, but Why
When making feature requests of developers, try to explain not just what you want, but why it’s important — how will this new feature make users happier?
Doing this is valuable for two reasons. First, it makes technical staff feel more included — you’re bringing them in on the planning, and it feels like you’re tackling the problem together, which will increase everyone’s motivation. And second, if there are features that would require inordinate amounts of time to implement, it gives the developers an opportunity to propose modifications that may decrease the difficulty of implementation while still accomplishing the same goal. This will help everyone to avoid missed deadlines and fatigue-driven software bugs.
Have a Clear Process
Work with the development team to come up with a clear process for the planning and building of new products and features. You want everyone to be clear on the vision up front, and you should also include regular check-ins along the way to ensure you’re maintaining alignment with the developers as the work is done. Make sure that everyone fully understands the process and that it’s important to stick with it.
A good process can help to more fully flesh out the product design up front, which will lead to fewer late-stage changes, and it will help to catch any confusion around product or feature requirements earlier on, when things are easier to fix.
There’s also no need to reinvent the wheel here — a lot of past work has gone into coming up with effective development processes. Check out Agile Software Development if you’re looking for somewhere to start.
Learn the Basics
The last recommendation is more time intensive, but if you expect to be working extensively with developers in the future, it can be well worth it: try and learn some key concepts of the technical work they’re doing.
It isn’t necessary to learn how to code yourself — all you need is a general understanding of the process they use for app and feature development. You can find many helpful resources for doing this on sites like Codeacademy, Treehouse, and Khan Academy.
Learning the basics will make it easier to understand where developers are coming from and to work through challenges that may come up together. It will also demonstrate to technical staff that you’re willing to put in effort to better understand what they do, which will help to generate good will and improve all future interactions.
—
Planning and building a complex, technological system is a difficult and unpredictable process, and there will also be challenges that come up along the way. But if you can learn how to communicate effectively with developers, it can make your life (and theirs) a lot easier.
Jim Pugh is the CEO of ShareProgress, a mission-driven startup that helps nonprofits and progressive groups achieve success through the use of data and technology.
