The Ideal Product Development Partner Relationship

On this episode I talk about: What your organization needs to own What your product development partner should own Owning the client relationship Prioritizing what to build How you work together to scale impact If you’d like to learn how to scale impact at your nonprofit by more than double in less than half the time, sign up for my free 5 day email course - https://nxtstep.io/impact/ Episode Transcript Hey everyone, Sean here and today what I want to talk to you about is how to develop an effective relationship with your development partner. Now, when I say development in this case, what I mean is product development or software development and the understanding is, at this point, you've decided that in order for your organization to better scale impact, you're going to invest in software and technology and you're planning to build something which is great. The question is, what precisely is it that your development partner is going to own? And then what are you going to own in terms of making this relationship work so that you can scale impact for your clients and customers? I'm going to break it down into a couple of different categories. And this is very relevant or timely because I'm going through this right now with a client of mine. They are trying to upgrade a product that they have and make it offer even more value for their clients and customers. Their product is a little bit dated, so there's quite a bit that needs to be done and it serves quite a large population of clients. So it's a pretty significant undertaking and as such, they need a development partner, and I'm helping them figure out how to effectively establish that relationship so that they can successfully accomplish their goals. and make progress towards their ultimate vision, and better understand who's expected to own what in order to make that relationship work. The conversations that we're having relate to questions like and topics like the what, the why the how and the when, in terms of what it is we want to do. Now the what you can really think of in terms of what it is we want to build. What do we want to add to the product or fix in the product from its previous version? The why is the validation criteria to better understand which of the category of the what in terms of the things we're considering building really should be built? Because we've got validation that says that those are going to offer value if we prioritize them. The how and the when is more related to how are we actually going to build it, who's going to put the technical pieces together to bring it to life? And the when is another priority component terms of if that will happen now or is that going to happen in the future? Right? How do we prioritize from there? So a good way to think about this is that you as an organization, are going to need to own the what and the why. The development partner on the other hand, is expected to own the how especially and will help you put together the picture of the when. Now, the what is something that you should be owning in terms of having conversations internally with your team and gathering this data from your clients and customers. If you have strong relationships with them and you're better understanding what they need help with, and combine that with your vision for scaling impact, then that should materialize into the what components in terms of what it is we want to build. Now in order to validate the what and make sure that we're not just picking things that may or may not offer our clients value. You need the why component and you should be owning that as well. The why comes from those relationships with your clients and customers. You need a process that I call customer discovery but you need a process for getting this data from your clients and customers to validate the what in terms of basically what should we prioritize out of this list? How do we order this and get a better understanding of how much value it's going to offer to our clients. Now on the other hand, once you've done that work, you're ready to establish the relationship and potentially move forward with the development partner, someone who can bring this product to life for you. They are going to provide expertise which will help you better understand how they're going to be able to do it and what's required there from a technical perspective, but they'll also help you better understand the when. Because you may have multiple things you're considering building and you're trying to determine which one to build and when the why component will help you validate what's going to offer the most value to your clients and that additional input that your development partner can provide you with in terms of basically how heavy of a lift is it going to be to build any one of those things? What's that going to cost? How much time is going to take? They can help you get that kind of data which can help you better understand what type of project are you looking for and as such, what should you prioritize now, so I wanted to share that with you because they're working through figuring that out and I've helped a number of different organizations, try to figure out this right balance. That's what it should be at your organization. You should own the what and the why. Relationships with your clients, protecting their interest, and making sure that what's being prioritized is getting you closer to realizing your vision. Your product development partner, when operating in optimal fashion and being a good partner will help you with the how and the when. If you'd like to learn how to scale impact at your nonprofit organization by more than double in less than half the time, I'd encourage you to sign up for my free 5 day email course at https://nxtstep.io/impact/.