Full Product Lifecycle pt.2 — Testing New Ideas Before Wasting Tons of Time and Money
Part 1 Recap
In Part 1: Introduction & Identifying New Initiatives, we went over how to identify business initiatives by empathizing with the users who will be utilizing your businesses’ solution. In summary, you should observe and interview them to get an understanding of their interaction and journey, which helps define problems the customer encounters. Figure out which problem would be most beneficial for your company to solve and that is how you identify a potential product.
In this article we’ll be going into what to do before investing tons of money on development by testing your concepts your the target audience.
What Ideas Should Be Tested?
New concepts that will be turned into large scale projects are ideal to test. The goal is to find out that if you invest the large amount it takes to build this product, it will satisfy your customer’s needs.
What Should You Know Before Testing?
The solution will come from knowing your customers and their journey so it is essential to have prior research before forming solutions. Testing can also help clarify some unknown information about your users if you weren’t able to uncover all of it. To that point, the minimum that should be known is who you think would use the product your business chooses to build.
Creating and Testing Your Concept
There are multiple ways to go about creating and testing your idea but the goal is to figure out a concept and get feedback around that concept from your customer base. A common exercise that allows your team to come together, create a concept, and gets results within a week is a Design Sprint.
On Monday, you map out and present the customer’s journey and get weigh in from experts that explain and elaborate on your findings. If the team working on this is different than who did the customer research initially, they can elaborate on their findings along with anyone else with expertise around the area the company has identified. You then go through an exercise in which you identify specific pain-points that can be addressed. If you already have a specific problem you’re addressing then that one should already be decided. On Tuesday, the team reviews inspiration then goes through some exercises to create concept sketches of ways your company can solve the identified problem. On Wednesday, the team presents their solution and picks which concept is going to be prototyped then create a storyboard of the selected concept will be used. On Thursday, the prototype is created for the test. On Friday, the test is conducted and the findings analyzed.
In summary, the goal is to create a prototype of your idea and put it in front of your company’s customers and get feedback around your direction before paying for months worth of design and development.
What Do You Do If Your Test Fails?
There is the chance that you test your idea and don’t get the results you were hoping to achieve. In this case, the solution your team came up with needs to be refined and retested before proceeding. You may have to start from scratch and do more research around your customers but hopefully the findings from your test should give some insight where to look.
Spending the time to get this knowledge and direction is essential to the long-term success of your product.
Next Steps
Once you’ve gotten validation and the insights necessary to ensure you’re idea is going to solve the identified problem, it’s time to start turning this into a tangible product.
Planning
You’ll need to hash out what is necessary to have a minimal marketable product(MMP). Notice we said MMP and not minimal viable product(MVP). Releasing minimal functionality without bringing any value to the customer will result in poor adaption so you need to be able to get to a marketable state before releasing.
Aligning With Development Structure
Along with knowing what must be in your MMP, you’ll need to understand what development can build and the amount of effort it will take. Companies commonly use development methodologies such as Agile, Spiral, or Waterfall to schedule how much work can be accomplished in a given amount of time. Once the product is launched there are issues that can and will be identified by the people using the product. Production support time should be planned to handle these issues. Another thing to take into account is that there is no design and other dependencies created yet. The design from the sprints was conceptual and might not translate to what was scheduled 1-to-1. Scheduling design and other dependencies ahead of development is necessary to ensure proper predictability of what will be delivered.
Conclusion
In order to prevent wasting tons of money on an unsure product, it is imperative to test(Design Sprint, etc.) a concept of what you want to build with who will be using your idea. If the results don’t show success, refine and retry until you can ensure what you build will solve the identified problem. Once you’ve gotten the necessary validation, the work needs to be scoped out into a minimal marketable product and planned to be built with the team that will be building it.
- Identifying new initiatives
- Testing the initiative quickly
- Implementing your initiative— article coming soon
- Understanding when a product is finished — article coming soon
Resources
Ritzie Design Studio is constantly on the hunt for knowledge and improving the way we design products. Let us know what you think in the comments section and follow us for more discussion around process and designing products!
