This post is the second in a series on Product Management for the AppExchange. The third installment: Planning for the Future: Roadmapping & Prioritizing post-MVP AppExchange Products can be found here.
Congratulations! You read about how to Identify Product/Market fit, found the business problem you want to solve for, and are ready to build a product on the Salesforce AppExchange. What features should you actually build and when should you build them? Where do you begin? You understand how to run Agile/Scrum so you know that you need a backlog for your Scrum team to start executing. How do you know what to put in it? In this post, we’ll walk through how achieve a buildable design that leaves nothing to the imagination.
Design Like No One’s Watching
Utilizing your pre-defined strategy and vision, it’s important to determine a cogent design that will guide the implementation of your application’s behavior. At every step of this process, there should be clear intellectual feedback to that strategy. In fact, the act of comparing and evaluating a design against the strategy is an excellent gut check that the process is a) on the correct path or b) that some aspect must be rethought.
UX, CX, XD, IXD…..Connect your users to the problem solution
Design your user’s experience deliberately. Every aspect of the product you build should feed back to a journey that your customer takes and that journey should be or support the problem addressed in the product vision. It’s all connected and exists cohesively. Sometimes it’s not easy to see when your product is connected to the vision but mis-connections are obvious.
Start with Personas – CodeScientist Rina Henderson explains why in this fantastic post about the importance of starting with persona audits and thorough design principles.
Map Your Customer’s Journey – Plan the end-to-end flows that your customers will experience while considering their needs that you identified during your persona design session.
Prototype!
Prototypes have a number of strong use cases but there are two main drivers. First, a solid prototype is an excellent tool for sharing common understanding about what will be built within the development organization. It’s tangible and leaves no room for interpretation. Executive sponsors all the way to the developers who will be coding the implementation will understand the target. Second is feedback. As we discussed in “Defining Product/Market Fit: Finding & Validating Market Problems for the AppExchange”, prototyping costs are orders of magnitude cheaper than pivot costs once development has started. Utilizing functional prototypes to collect feedback from customers so that any direction changes can be taken early is always more efficient.
A prototype is your cheapest way to fail. Hopefully you will succeed. If you don’t, think of all the money you saved!
CodeScience Design Sprints
At CodeScience, we have team of amazing Unicorn Wranglers who specialize in the tactics of rapidly prototyping your designs for customer feedback and build. We utilize a tactic called Design Sprints, which are a front-loaded design engagement to prepare the assets for the build phase. Contact us if you think this effort can help you define your MVP.
Build Your Backlog
All the work that you have done to this point has been in service to getting the correct minimum viable product built, but an ancillary effect of it is that the build team doesn’t have to assume ANYTHING in the course of the build. We, as humans, all have unconscious biases; the following video explains how we can work around the bias that we all carry inside:
Google Video on Unconscious Bias – Making the Unconscious Conscious
Utilizing all the work done to date: Problem Identification, Vision, Strategy, Persona Definition, Customer Journey and the Prototype, create a backlog of user stories that drive the build of the product that has been defined. I will not dive into what makes a good user story, far too much work has already been done on that topic. Mike Cohn over at Mountain Goat Software lays that out extremely effectively.
Voila!
You now have a backlog of features to be built in service to your MVP and a collection of strong assets with which to communicate those features to the development team and stakeholders. In a future post we’ll discuss how to prioritize and roadmap features for the world post-MVP build. The third installment in this series on Product Management for the AppExchange, “Planning for the Future: Roadmapping & Prioritizing post-MVP AppExchange Products” can be found here.
