Are you delighted with your product development partner’s code? You may only be getting half of what you paid for.
Tell me if this sounds familiar. You’re working with a partner whom you selected over a period of weeks and months, amongst a who’s who of candidates. You’ve now been working with them for a decent length of time – long enough to develop and release your custom app or platform. Things are moving right along. User stories are being knocked down, tickets are opened and closed in rapid succession, and you are pushing software to production regularly with few if any bugs. So, you’re happy with your partner, right? Right?
Well, if they’re performing to the Statement of Work you labored over at the beginning of the engagement, all should be OK. And no one from your company is threatening to quit if you don’t fire the partner, right? So we should keep things as-is. Sounds like a great situation. Except…
Something’s missing, right? Don’t you have a nagging feeling that you should be getting more from your partner than you are today?
You are correct. In fact, you couldn’t be more right. So why aren’t you doing anything about it?
Wouldn’t you do something about it if I told you that you could be wasting 15% of your development dollars because your contracted partner isn’t in lock-step with your business, product and technical owners? Or that you may be missing out on 25% of the velocity you could be getting if only your partner were coordinating work, prioritizing tasks, optimizing processes, answering questions, asking questions, and removing obstacles – as they should be doing?
At 3Pillar, we believe that a high-performing team will regularly outperform the sum of its parts. The best software products benefit from the ideas, productivity and discipline of a well-formed and collaborative, cross-functional team. These teams also eliminate waste and get better results in shorter timelines.
So how do you get there? And what should you be doing as part of your software development practices – even if you don’t want to spend any more than you are today?
Short answer: Demand more, and specifically in the area of quality of experience that leads to better-performing teams. Is this too much to ask? No way. If you are like the active clients in our portfolio, you’ll agree that your customers or constituents are asking for more. So don’t sit still with your product development partner; your customers certainly won’t if you are in a competitive marketplace.
But in what areas should you be asking for more so that you get the most from your services provider?
Sometimes it’s hard to think about this without some fuzzy, feel-good buzzwords getting in the way. Maybe the best way to think about it is to add another dimension to the expectation from your partner. You probably already have some expectation of the quality of the code. But what about the quality of your experience with your partner? Take a look at the 2×2 here (note that I am a recovering management consultant, so a 2×2 chart typically finds its way into my documents). Which quadrant are you in today?
If you want to be in the upper-right quadrant (and who doesn’t?), I’d say that you should be asking your product development partner for the following to improve your experience:
Commitment to a long-term relationship – note that this doesn’t mean for you that it’s a “commitment to pay fees from now to eternity.” This means that both you and your partner commit to the notion that software is never truly done. Again, on both sides, this is not an agreement that a project goes on forever. It’s the acknowledgment that your software product will need to evolve, and your partner is committing to – and has the ability to – evolve with that product.
Collaboration on steroids – your team and your partner should communicate well and regularly, openly and honestly. There should be no daylight between their views on developing and evolving your product.
Managing change as part of the engagement – no one is perfect. And the optimal team your partner put in place at the beginning of your engagement may not be optimized for your needs today. Unless the health of your engagement is constantly being monitored and tweaked as needed, you’ll have a drag on your output. You – and your partner – should have the ability to raise your hand, state the need to change, and provide compelling reasons why.
Maybe I’ve got you thinking now. But maybe you need to bat your thoughts around some more? I’d like to help. Tweet me at @mlisse, or email me at firstname.lastname@example.org with your biggest concern. I’ll spend a few minutes with you, we can talk core issues about your development team, and hopefully you’ll have better output than you were expecting in 2018.
If you like what you read here, please help us spread the word via the Click to Tweet feature below or the social media icons at the bottom of the post.Working with a product development partner? See why @MLisse says you should be pushing them to find product development nirvana. Click To Tweet