What Can a Product Development Team Do for You?

Starting your first project can be challenging. You probably have no idea what to expect, learning a lot as you go. Stakeholders often get frustrated with their development teams when their expectations were too high and not aligned with the reality of bespoke software development. 

One thing I consistently see even with experienced product owners is just how complex development actually is. Software development is hard and expensive. If you go to a mechanic and ask them to fix your Honda it's going to be cheap. If you want to fix your Porsche it's going to be a bit more expensive. If you want them to build a custom car it's going to get pricey quickly. This is also true of software development. Building custom software is like building a car from scratch. Hiring experienced teams to build your product can make the process cheaper than going with a vendor that is untested but the challenges are still there. Software development starts with lots of assumptions. We use wireframes, UI and UX designs, technology choices, technical challenges, and research to try to test these assumptions, but some will still remain until the time comes to actually build the solution.

I believe a lot of stakeholders and even end users believe that building apps is easy because they interact with apps all day long. Hindsight always skews assumptions to be more positive. If I spend 12 hours trying to understand how the internals of a library work and then give you a 15 minute breakdown, it’s unlikely you would know that it took me 12 hours to understand all of that information. Software development is a continuous innovation and invention process. This means your development team are primarily researchers. 

Development is risky in more than one way. The most obvious risk is being unable to find market fit after dedicating a large amount of time and money building the application. Some philosophies have emerged to try and reduce this risk. For example, The Lean Startup attempts to reduce market-fit risks by first analyzing market fit without building anything and then building an MVP to test the waters before committing 100%. 

There's also a risk when it comes to budgeting. You could allocate enough budget for a project that goes smoothly and then come across multiple technical challenges that cause your budget to spiral out of control. You might also budget too little which causes your development progress to slow to a rate that allows a competitor to corner the market. Conversely, budgeting too much can affect your return on investment which will increase pressure from stakeholders in the post-development phase.

 

It's possible you may also run into unexpected issues that cannot be solved with the technology currently available. Perhaps your business plan relies on an integration with a 3rd party that turns out is not yet available. 

It's important to go into the development process understanding all of these risks and assess everything as well as you can. If you don't have the answers, you should consult experts before going too far. Most things can be worked out if you speak to the right people.

Your development team can help unearth a lot of answers to questions you may have. A good team will be able to help research and uncover technical risks, limit financial risks, and help you discover if you have a good market fit. This doesn't mean that you can expect them to completely remove those risks. It's also important for you to own these risks. Attempting to move the risks onto your development team is not only unfair, it's also asking for a conflict of interest. You need to build a relationship of trust. As soon as you start trying to shift risks, you are increasing risks of developers taking shortcuts, hiding information, or worse, lying to you.

An experienced development team should be able to provide business insights and help guide your decision making process. When we work with clients we don't just offer development services - we offer a wealth of knowledge. We help guide our clients whenever we can. This advice is either given from experience or through fact-finding. 

At a minimum, any team you choose should be able to give you clear information in a format that you can understand. Periodic updates and status reports should be offered as a default. If your team runs into issues, they should notify you as soon as they recognize them as more than a bump-in-the-road. Great development teams will be able to see risks before they become an issue and will be able to guide you in your options, ideally presenting ways to work around them. 

We also offer guidance on how to prioritize work effectively, determining which features deliver the most value for your customers. Building a backlog of tasks in a clear and effective way is a skill - your development team should have strong opinions on what works well. We highly recommend following Agile principles when it comes to planning and shipping features. Your team should be able to clearly articulate their processes to help you understand why things are being done in a certain way. Disorganized development is slow. If your team doesn't have a strong set of processes in place, that should raise a serious warning flag. If stakeholders are changing direction too often, your team should be pushing back. Take their advice. 

Ideally you should allocate budget towards documenting your application to help both your future developers and your internal staff. Your development team should be able to deliver both technical documentation and user guides in professional formats. Be wary of teams that rely on spreadsheets to deliver documentation. 

Do you still have questions? If you need advice or want clarification on any details in this post feel free to either leave a comment or contact us below.