Why your software developer is also a business leader
Few who buy software development assume that they’re actually hiring business leaders at the same time. Yet companies still saddle development teams and firms with business-level responsibilities, intentionally or not.
Both small and large companies give away business leadership unintentionally. Typically, this starts with an obscure brief or a request for proposals that leaves development companies wishing they had the power to read minds and decades of expertise in the client’s line of business. If the development company nevertheless takes the project on, the next step might involve an insecure or distant product owner on the client’s part.
When a project starts like this, the development team ends up in digital no man’s land. Left to their own devices (pun intended), the team will eventually come up with an entirely new line of business for you. It just may not be the one that you had hoped for.
You have to constantly bring your domain understanding to the developers to make this work.
Value your data
The people who decide which product features end up in your digital service also decide what types of data can be gathered about your customers. And in digital business, data is your business and intellectual property. It’s you who should be in charge of that.
Don’t get me wrong – I’m not saying that the product owner should plan the service, its key features and design alone. The design and development team has a big responsibility and must have a clear understanding of your business, customers and even strategy. A seasoned development team can tell the business value of user data and what can be enriched from it.
Channel product owner leadership into something constructive
An empowered and well-led development team is a valuable thing to have. You win by helping them feel comfortable saying “no” to overly expensive feature requests and incentivizing them to design and develop user-centric and cost-effective solutions. Hire great product owners — or train the people you already have. For instance, we at Qvik organize regular product owner meetups to help our clients and even third parties share best practices with each other.
Work with a development company to develop better RFPs
If you’re not too sure of what your minimum viable product should include, you really shouldn’t ask for an offer to build one. Instead, you need to find out what that MVP is. Keeping it simple is often surprisingly difficult. It may require an intensive design sprint or a prototyping session to get you to a point where your MVP requirements are worth putting together.
Even when you believe you have the MVP specs nailed, you might want to consider paying a development company to go through your RFP to see if you will be likely to get the kind of offers you want. This is still fairly rare, especially considering the potential gains of a couple of hours of work.
It’s never too late to learn — but it can be too late to measure
Even before you start planning a new service, you should be able to distill some insights from your existing services. It probably won’t pay off to track every single datapoint a mobile app or website can generate. One thing is certain, though. You can only learn from what you measure. Tracking many more events than you anticipate to actually use guarantees that you and your development team can gain insights to support your business decisions and guide your software development. Remember that it usually takes weeks or even months before you start to get useful analytics.
Make sure that your plans for the MVP and your RFP include solid and well-explained key performance indicators that a development company can compare against while making an offer, building the service and eventually developing it further.
It’s in the best interest of clients and development companies to create true partnerships by starting from a level playing field. Hands can be hired but you can also turn your developers into empowered business leaders!
