We’ve all seen this image and in healthcare IT industry, we have all faced this over and over. Most failures occur due to breakdown of communications and expectations – not the lack thereof.
Maybe if you approach product requirements in the following way, you can really bring the entire product team together (in the “cool” agile way). Give it a shot – your mileage may vary.
- Start with the problem. This is nothing new and no one needs to tell you that. You already know it. List down what you and your colleagues are tasked with each day. Jot down why you do those tasks (ie what you’re being measured against and why doing those tasks accurately and efficiently will get you your desired outcome – promotion, bonus , recognition, whatever that might be).
- You will notice themes developing.. you’re do X. You have to do X because it achieves Y. You have to achieve Y because your colleague needs Y to get their stuff done. They need Y because it helps your company deliver Z to your customer. And so on and so forth.
- Each one of those X and Y that you need to be able to deliver to your customer? Guess what? Everyone in your industry needs to do the same or something similar. So, when your product marketing team needs to market, they just need your one liners – advertising how it’s easy to do X or Y with your solution. It’s that simple.
- So, now you have the product marketing and product owners on the same page. You need to get the product development team on the same page as you. This is why you have to write up all the requirements anyways.
- As a business user, jot down the exact steps you take each day to do X. This goes across the cohort of users that will use the solution. Each one of you has specific responsibilities and you are currently doing them in one way or another. List down the steps for X, Y and finally how those are “measured” – the same way you’re measured for doing them anyway.
- Once you jot each of those down, you have, effectively, defined the success criteria for your product manager, quality assurance staff. If the solution can do such and such to help me achieve X or Y, and if can be proven by measuring this or that, it is acceptable to you.
- This very set of documents that you have created? Give them to whoever on your team is going to write up the user manual / guides for the solution. Let them collaborate with the product designers and create user manuals even before the product is created.
- Publish these documents internally or externally with pictures/ videos (eg blog posts). We prefer posting them externally because it forces your team to commit to something. At the same time, even before you launch a solution, you benefit from google searches and jump start your marketing.
- In addition to the benefits just mentioned, this acts as the guide posts for your quality assurance team plus your development team. They know exactly how to develop and test whatever in the world they’re developing.
- While the product development team is off doing their own thing, start preparing test data. You have all the test data you could possibly want. If you don’t have test data, you know how to create test data better than anyone else. Go ahead and create that. Hand them over to your product quality assurance team. Tell the, that if this kind of data is used during the quality assurance process and all looks well, then you’ll accept the delivery of the solution.
Try this out. Making these little changes to your product development processes could bring immense value to you and your team. It will help you truly function as a single unit instead of lobbing things over the wall at each other.
Maybe this will help some product marketing and product management teams