Every product owner has to make 100s of choices daily — do I recommend our client to take this direction, how do I best communicate this feedback, this versus that, up versus down. With this myriad of choices, it is important for product owners and managers to share what they’ve learned along the way.
That’s why we have a weekly call where all our product owners, managers, and business analysts come together to sync and share industry knowledge. One of our product owners, JT Lovell, shares some common pitfalls that project managers face and answers the question, “just because you could, should you?”
**JT adds as a disclaimer that these are general best practices and there are perfectly valid reasons to break these rules based on the circumstances.**
You Could…
Skip some scrum ceremonies to save time and budget
You Should…
Avoid that in general — it will almost always come back to haunt you.
This is most common when you facing a project that is coming to a rolling stop. You get to the point where you feel like you are burning hours and budget with your team having scrum ceremonies. When this situation arises, at a minimum, announce to the team that you are breaking from this structure and moving to some other style (Kanban, etc.) instead of calling yourself sprinting (which you aren’t).
Thoughts like skipping retros, not needing sprint planning, or believing you can do story grooming during your sprint planning call, all fall under this category as they will generally come back around and cause issues down the line.
You Could…
Put specific integrations to third-party apps inside the package.
You Should…
Build integrations as extensions (unless all package integrations are the same).
Let’s say your client really wants to integrate with the latest and greatest app on the market, and they have a contract signed and are ready to go. You could put this app inside the package; however, when the contract comes around for renewal, the client will almost inevitably want to change to another provider. This requires reworking the package integration and rewriting code, which can, over time, make the code overly complex.
The benefit of building your integrations as extensions is that the packages are developed separately and can be tied and untied in a much cleaner way. This also allows you to build for scale. If your client is delivering their app to many different clients who each have their own third-party apps and you integrate them within the package, it becomes overly complicated to switch out these specific integrations where they may not be applicable. By building an extension, you can customize the experience for clients in a much simpler way — because they are developed independently.
There is a caveat if your client owns the third-party app they want to install. If they own it, you can have greater confidence that it won’t be switched out within a year or two.
You Could…
Put every feature in a specific extension package so they can be managed independently.
You Should…
Use extension packages, but try to keep the overall number within reason.
This should serve as a counterpoint to the section above. While some think it would be great to have each feature sitting separately in an extension so they can be built and iterated faster than the core application, the flip side isn’t often considered. There is a CI stack, a repo, and likely a dev org and an entire stack for integration QA orgs for each extension. The problem with building all these extensions is that if they rely on anything new in the core, you have to actually build the core release and get it upgraded before you can develop on top of it.
You Could…
Add every possible feature to a new app.
You Should…
Build the most important features and then get user feedback before building the less important ones.
While this may seem like PO101, it is important to keep in mind because many clients will push the line of what is Version 1. This helps keep the client honest with themselves and establish what they need to go live (i.e., in scope for the first version) versus creating deeper functionality.
For your Version 1, start with the features you have to have and then circle back to the nice to have features. That way, if you were to run out of time, you can drop off the nice to have functionality and still have a fully functioning product available.
Where we at CodeScience always come back to is challenging, questioning, identifying alternative solutions, and providing guidance to our clients of what is truly most important and answering the most important questions first that they want to prove out.
Part of what makes CodeSciecence so great is that our team members share their experiences from each project with the broader team. As we continue to solve hard problems, we grow our skill set as a whole. If you are looking for help building your product on the Salesforce AppExchange or looking for ways to better leverage the platform, get in touch today!
