November 13th, 2024, posted in for_founders
by Adelina
Developers are quite complex beings. But they’re still human, and the best way to connect with them is to understand how their minds work. When building software, as a product owner, you’ll interact with them a lot, and how well you do that can greatly affect your final product.
It might seem like they’re too technical to interact with, but that’s their strength. You’re bringing them ideas which they’ll have to turn into code, so they’ll look at them in a very pragmatic way. This helps them figure out how to turn your ideas into leaving, breathing apps.
So it begs the question, what makes developers different from the rest of us and how can we make use of those differences to build better software products?
In this article, we aim to answer that question based on our many years of experience in building complex software. Though, we can’t give one size fits all-type advice, as everyone is different. But we can give you a few general tips on how to understand and work with developers better.
They split big chunks of work into smaller pieces
You’ve come with an app idea (or scope) to a team of developers. You’ll tell them the app aims to help a group of people achieve a goal, like, let’s say, book a hotel room. Developers won’t know right off the bat how they’ll code the hotel room booking feature - they’ll think about all elements that lead to it. Such as, creating a list of hotels. Creating the ability to search through them. Adding availability data to all of these hotels, so that users can find which rooms are available at a given time, and so on.
When beginning a new project with a team of developers, and you tell them what features you want in your app, you’ll tend to look at the big picture. Whereas the developers will think about the small steps it takes to get to those features, as that’s how code works. You can’t tell a chunk of code to book a hotel room. You have to tell it to build a list of hotels, add details about their rooms, when they’re available, the ability to be searched through, completing a form in order to file a booking, and getting the booking sent to the hotel.
This taps into the Agile development methodology, where development work is split into sprints, which are groups of tasks developers will work on at a time. Working this way helps organize tasks in a gradual and logical way, where the most general and fundamental tasks are done first, in order to get to the more specific tasks. For instance, they’d start with a setup, building a database, and organizing the app architecture.
So how does this affect a software development project, business-wise? Well, don’t assume the developers will be able to give a development estimate for an entire project right away. They’d have to see it split into multiple tasks and estimate those individually, as it’s easier to picture more specific chunks of work.
In our process, as we take a design-driven approach, we’d begin by mapping out all user flows and designing the entire app. Once that’s done, we have a visual foundation for user stories, which will then be turned into development tasks. And so, when a project reaches the developers, they’ll have their smaller pieces of work all mapped out.
“What does this button do?”
Developers need to know more than the fact that you want your app to book hotel rooms. What will the app’s start screen be? A direct search? What can users search by? Do users need accounts to book a room? What data do they need to provide to book a room? Do they need to pay through your platform? And many more.
When developers are presented with a list of goals an app should fulfill, they’ll see an entire suite of features that require different chunks of code. They literally will ask, “what does this button do?” and it’s important to give them all the answers they need. They’ll have to know what happens when a button is clicked, does it look different when it is (does it turn into a lighter or darker color to show that it’s active?) and what process it triggers, and the steps involved in that process.
This is why a design-driven approach is so efficient: when an app has been fully designed before heading into code, especially if the designers use prototyping tools, developers won’t have to ask what every button does. It’s all right there, in their face. Even more so when provided with detailed user stories. User stories, especially, can be of great help for developers and are a key part of what they do. They describe every action within the app so the developers will know exactly what to do.
Source: https://dribbble.com/shots/22274203-User-Stories-UX-Research
But if you’re starting from scratch, be prepared to explain to your developers what every tiny thing in the app is supposed to do. Don’t make it a guessing game, as they might guess wrong and delay the project launch, or build something you don’t want or need. This might not be very productive, which is why we go for a design-first approach, which ensures having a clear list of flows and features with a visual reference.
Making them ask about every feature can become annoying, as developers might end up asking you tons of questions and you’d spend a lot of time replying. So be prepared to sit down and type, as giving them the information they need is crucial in building good software. Which gets us to our next point.
Communication is key - and it goes both ways
Developers aren’t mind readers, and neither are you. Good communication and transparency are important anywhere, but when building software it’s crucial. Developers need to know enough details about what they’re building in order to build it well, and to work as intended. There’s no use to building software that doesn’t serve anyone.
And so, this means that as a product owner, you must provide all key information to your developers. That means explaining what you want the app to do and how you want it to do those things, who will be using it, what role they have within the app, what different courses of action users can take (what happens if they do something wrong?) and what results those actions can lead to. Simply put, they need to have a clear image of the app’s user flows, including all possible edge cases.
If your app serves a more complicated industry or activity, it’s even more important to communicate well with your development team. You’d be inclined to use complex terms, as you’re familiar with them. But your developers know code, and not molecular biology or astrophysics. Take the time to explain all complex processes involved in the app you’re building. Use layman terms, analogies or clear examples to make sure they understand how your business works. And if it’s a SaaS product, take time to explain who the app users are and what they do.
In general, it’s important to keep communication channels open with your development team. Hold daily or weekly meetings discussing development progress - this helps you keep track of what’s being done and how well it’s going, and it’s also a good opportunity to answer any questions the developers might have.
Aside from meetings, use common communication channels such as Slack and Discord to keep in touch with the developers as they work. This will help them reach you faster and get answers to their questions or get your feedback. Let them know when you’re available and reply as quickly as you can. And, of course, it goes both ways - you can also quickly ask them for updates as well.
Small dev tasks can take up to weeks to solve
This isn’t a matter of mindset or psychology, but it’s something you should be aware of before hiring a team of developers. When you look at a user stories document, you’d think certain tasks can be solved within one day. But that’s not really how code works: just the smallest thing can take thousands of lines of code.
A filtering feature on a table, for instance, might be a simple dropdown in a design. Which might not look like much, and you’d think it won’t take long to code. But filtering means sorting table elements by given criteria: if your table is about fruits, maybe you want to filter them by the season they belong to. The code will be told to search through the seasons attached to each fruit entry and only bring up those with the season you chose. This has to be built into the existing page and must be done carefully, so as to not break existing page elements.
Put simply, it’s meticulous work, especially when trying to avoid bugs or issues. Even more so if the task in question is a new feature added on top of existing code. This means that the developers have to go through the existing code to see how it’s done, how the architecture is done, and they have to understand the existing structure so as to add to it without issues. This process can become more lengthy if the code is made with older versions of the technologies used and updates are needed. This can mean rewriting tens of thousands of lines of code.
Now, dev tasks won’t take long without the product owners or app stakeholders knowing about it. Through the Agile methodology, sprints will only contain as many tasks as can be fit within the length of that sprint (usually 1 or 2 weeks). Sprints are usually planned ahead based on task estimates, which are usually done before the coding starts. In our process, for instance, app stakeholders always have access to the user stories document, which shows how many hours were estimated for each task.
Setting aside these estimates and the general fact that small features can take a while, issues can always arise during coding. Alongside computers breaking unexpectedly, crashes, server downtimes and other external issues, bugs are an inevitable part of coding and they can take longer to fix than expected. Estimates usually cover these risks, but developers can’t predict anything. Software development is never risk-free and unexpected problems can arise at any time - and developers aren’t always to blame.
And of course, since you’ve hired this team, don’t hesitate to talk to them and ask how long certain tasks will take and why. Ask them to explain in less technical terms if needed. As we mentioned in our previous point, communication is really important when creating software.
Overall, developers aren’t too different from non-technical people, and to work better with them it’s best you first understand what they do and how that works. Be understanding and communicate with them as often as needed. In other words, if you don’t understand why they’re doing things a certain way, just ask. Bugs and issues can occur due to lack of experience, but also due to external factors. To tell the difference, ask them for as many details as possible, or make sure your dev team is led by a senior who can oversee all work.
If you’re looking for a team of developers to build some awesome software, contact us and we can discuss technical solutions together.
