What To Expect From Your Product Development Team

Over the years, I have seen business people and stakeholders become frustrated with the teams who make custom software for them. It’s understandable! Few people have any preparation for their first custom software project. They dive in with enthusiasm and subject matter expertise. Sometimes, it goes great. Sometimes, it goes poorly.

I believe that the key to navigating these waters successfully is understanding what your product team can and cannot do for you.

Why It’s Harder than You Think

Custom software is complicated

Custom software is hard, complex, and expensive. Sometimes, stakeholders don’t properly appreciate just how hard, complex, and expensive it can be. Why is that?

I believe it’s because most people now interact with custom software all the time. They assume that because they can see it, interact with it, and (to a degree) understand it, it must be easy to design and make. They confuse the mass-produced product they hold in their hands with the effort it took to invent the thing in the first place.

Accompany me in a thought experiment. Pull out your smartphone. It’s a supercomputer in our pockets with a ubiquitous connection to all the information mankind has amassed over thousands of years. How many man-hours did it take us to get to that device? It’s incalculable. Yet an economy smartphone costs about $250 to manufacture.

When creating custom software, we aren’t working in mass-production. We’re working on invention. To present it allegorically: We aren’t building a car, we’re building the first car.

Henry Ford started building an internal combustion-propelled vehicle in 1893. He wasn’t able to release the first Model T to the market until 1908, 15 years later. For Henry Ford, building the first version of a thing was hard, complex, and expensive. After that, Ford’s assembly line quickly ramped up to mass production. By 1913, Model Ts were rolling off production lines in Detroit every two-and-a-half hours. That’s 876 times faster than it took to create the first Ford car.

Custom software is risky

There are so many different types of risk inherent in building custom software. For example,

• Technological Risk: Some teams get a project about 80% done and then find out that early architectural decisions or lack of automated testing make it impossible for them to complete the project. Or maybe a key integration with a foreign system that’s necessary for project success proves impossible.
• Financial Risk: Estimating and budgeting for custom software is tricky (although we’ve gotten pretty good at it at Atomic). If you budget too little, a project can run out of time before getting to a release point with a meaningful scope of features. If you budget too much, you might not get an adequate return on your investment in the project.
• Product Risk: Alternatively, you might be able to build the right thing with the right engineering approach with the right amount of money…and still fail. Why? No one wants to use the software product you built; you made the wrong thing in the right way.

Enter Your Product Development Team

What they can’t do for you

As great as a product development team is, they cannot eliminate risk or make custom software easy, simple, and cheap. If a stakeholder is feeling the burn from the aforementioned types of risk or wants custom software to change its nature, I have bad news. It might be that the need or budget for custom software just isn’t there. Or it could be that the size and complexity of the task was underestimated.

Even the best product team can’t change this fact. It may just be time to go back to the well and the drawing board to prepare to try again.

What they can do for you

Enough about what a product team can’t do! Let’s talk about what they can do for you.

1. A product team can and should communicate essential business intelligence to you in an approachable and understandable way.
For most stakeholders, this business intelligence comes in the form of wanting to know about project status and when their custom software will be done. Well, a product team can help you answer that if they are using a burn up chart. They can give you an indication of how many Agile sprints it will take for your project to reach a certain completion of functionality scope. They can also help you decide if you should cut scope or add budget.

2. A product team can help you identify risk, suggest options to mitigate risk, contain risk, avoid risk, or ignore risk.
As I said before, risk is inherent in custom software. A good team will identify it and call it out early and often. They will also look to address risk sooner rather than later. They do this not to give you a coronary, but to keep risk from becoming a critical, blocking issue that prevents them from making progress. No one wants that. The team will need you as a stakeholder (and most likely subject matter expert) to orient them to the value in the project. The team will want to go after the riskiest, highest-value parts of the project first.

3. A product team can serve you with accurate information to the best of their knowledge.
They should tell you the truth about project and budget status, even if it is information you don’t want to hear. Most product teams are naturally incentivized to surface accurate information to stakeholders. Inaccurate information promotes mismatched expectations and the possibility of failed projects. The product team doesn’t want that any more than you do.

The Importance of Trust

A trusting relationship is essential to a successful project. Your team’s responsibility is to give you accurate information so you can make smart business decisions. This may include the team telling you things you don’t want to hear.

For example, your team might tell you that a certain feature is much more complex than they originally thought. This could mean your next release won’t include all the features you want. You may have to go find a way to increase your budget or delay your release if you want all those features.

This is always tough news to deliver, but knowing is better than not knowing. By knowing, you are able to take steps to solve problems, mitigate risks, and overcome shortfalls. Your team needs to be surfacing risk, offering you options to mitigate that risk, asking for help to solve problems actively blocking them, and informing you about progress through scope as time and budget pass.

Beware an erosion of trust

If you start to feel like you can’t trust your team to tell you the whole truth, ask yourself, “Why wouldn’t they want to tell us the truth?”

There are a lot of answers to this question. The team could be hiding a lack of technical knowledge. They might not want to disappoint you. They could be afraid for their jobs.

Think about how you’ve been treating them (and be honest with yourself). Is there anything you’ve done to inhibit them from telling you the truth about the status of our project? Is there anything you could do now to encourage them to tell you the truth?

For example, have you been playing games with estimates, trying to strong-arm them to get more done faster? This is a short-term strategy that imperils long-term success. By pushing, you might get to 80% completion a little bit faster, but you’ll end up with technical problems that prevent you from ever getting to 100%.

After some self-reflection, ask your team these same questions. Be sure to do everything you can to make this exchange psychologically safe for your team. Having these sorts of open and honest conversations can reconnect you with your team and re-establish trust.

Why is this so important? Trust promotes communication of accurate information about your project.

Custom software can be an incredible tool for business. It can unlock value and financial gain that was previously unimagined. If it didn’t work, people wouldn’t turn to it as often as they do! But it isn’t without peril.

If you’re going to develop custom software, leverage a product team effectively to ensure success. Find a team you can trust, don’t underestimate the difficulty inherent in custom software, and trust your team.

‍