Being able to define what fits or doesn't fit into a product and ultimately choosing what to include/exclude defines product scoping. Of course wanting to include every bell and whistle on your list would be ideal in a perfect world. The truth is most of the ideas that are on that list won't work and the opportunity cost of choosing one feature over another is a slippery slope.
Truthfully, even when prioritizing the 'best' features that have been throughly vetted and tested pre-development, there still isn't a 100% guarantee that people will respond the way you would have hoped. I say this because the world is ever changing and evolving with innovation at its helm. There will always be a new feature and a better product. Competition is fierce. This makes it important to constantly ship work because if teams aren't shipping then they aren't delivering value.
Products that are waiting in the queue with ready to add functionality are not benefiting the customer. You could be working on a time travel machine that could help reinvent the world, but if you don't deliver then the product can't have an impact.
This doesn't mean the quality of your product should suffer and that releases should be given out like Tic Tacs. Remember, it's important to protect the reputation of the company and prioritization should be given to features that could potentially harm the brand.
Iterative Development and MVP
Similar to breaking down features into easily digestible user stories the same approach should be applied to releases. Launching everything as a 'big bang' can be catastrophic so it's important to have well thought out releases.
Taking an iterative approach when rolling out features creates opportunity for improvement. If you roll-out feature A and the feedback from customers is mediocre, but feature B is in alignment with feature A it will give opportunity to pivot. This encourages more frequent changes through feedback you are receiving.
Developing in iterations aligns with MVP delivery. MVP is referred to as a 'minimum viable product,' but don't let the name confuse you. Just because it says 'minimum' does not mean rolling out a subpar prototype. It's actually quite the opposite and should be very good at what it does to deliver on working functionality.
An MVP is the simplest thing you can build that performs the core function effectively. - Product Girl
All customers care about is the core functionality. This makes an MVP so crucially important. With each release you should be delivering on core functionality to make sure you aren't wasting time building things customers don't care about.
At the end of each iteration, whether it be a sprint or a continuous deployment, the product should deliver on working functionality and constantly be improving. See below...
In the first example, the work was split into multiple releases. In each subsequent release working functionality was not achieved. Therefore the team could not learn what customers would use or wouldn't use because no customer value was delivered.
In the second example, the team shipped working functionality with each release. The first iteration, may not have been perfect and most likely didn't satisfy the customer needs, but with each iteration it gave the team an opportunity to receive valuable feedback about what customers truly wanted. Ultimately, they ended up building more than just a car they built a convertible that customers love.
Therefore, delivering value incrementally and early on will help validate ideas and assess the landscape of the direction you are heading.
Breaking down the launch
The scope of your release needs to be perfect. Leaving out important functionality can result in an unsuccessful launch. Just remember the features you choose to launch with MUST translate into a fully functional working prototype. This means you could not launch with just the wheels of a car, but you could launch with a skateboard. A user could not get from point A to point B with a pair of wheels, but with a skateboard they could hop right on.
There are various ways to split a product into multiple releases for a successful outcome. Some of these ways include:
- Risk Tolerance: Releasing to users that aren't very picky and can tolerate imperfections in the product. This includes: bugs, missing/lacking functionality, and UI hurdles.
- Hierarchy of need: Create a list of users with the simplest needs and what they expect. Then, work your way to the more complex users that expect more from your product. Split users into three categories: ones that use a competitors product, ones that are on the fence and comparing your product to others, and users that aren't currently using your competitors product.
- Target Persona: Create a list of requirements for each persona and what they expect. To start, target two different personas for comparison. For example, maybe you build a product that is great for someone who isn't knowledgeable about the space, but then the user experience can slowly be built to accommodate more knowledgeable users.
Cost: Always check the list of cost estimates. Find workarounds, but not at the cost of the product.For example, starting with an existing component for a pop-up modal as opposed to a brand new customized option.
Be aware of scoping too small
It's important to take an iterative approach in development so that you can launch early and quickly to validate customer feedback. When scope is too small it can affect cost, potential gains and lead to scope creep.
Don't box yourself into thinking that you can only include work that is absolutely required and necessary for launch. Take a step back and survey the 'nice to have' and 'delighters' with the engineering team. Discuss and evaluate the pros and cons of not including these items. Sometimes the 'nice to have' and 'delighters' can make a customer happier and increase the chances of the products overall success.
Accept that you may not have all the answers
Ideas are hypothesis and even though you may think you have the next million dollar idea a lot can happen from product discovery to deployment. Practicing humility, staying humble and accepting that your hypothesis may not be correct will be a part of your growth.
Understand that you may not have all the answers. Don't be disappointed when you thought you knew what customers needed/wanted and you went through user validation only to find out that your hypothesis was wrong. Even with extensive user research an idea (hypothesis) can go in a different direction. There could be a gap between how they use a product under observation and how it's used when not being observed. In my article on User Insight I discuss this and how it can affect the anticipated outcome.
Find ways to optimize for the right time frame-Use your judgment
It may not be beneficial to deploy with an MVP or a smaller scope. It may make more sense to work on items that take a little more time, but save time in the future. For example, it could be more cost effective to make changes in the code base while the work is still active, environments are set-up, and pipelines ready to be deployed.
Being rigid and having rules in place won't benefit the product or the teams in the long run. Having flexibility and knowing when to pivot will help to determine what should make it into a release. So how do you measure when it's necessary to add more polish or functionality and when the benefits outweigh the opportunity cost. Consider the following:
- Cost of work: How much time does this added feature add to the project? What's the percentage? If it's minimal and adds value and you can still hit the deadline...consider it!
- Customer/Business Benefit: If it will be very influential in the overall success of the project...consider it!
- Team Morale: If a teammate is really passionate about wanting to add this piece of work and it doesn't cost much time...consider it!
- Time Frame: Should you slowdown work if you won't see the fruits of your labor for another 18 months and the project needs to be completed in 6?something to think about...
Keep your hypothesis simple
Have you ever been in a meeting where people are saying something different, but trying to say the same thing? It's almost as if they don't know how to zone in on the problem and communicate it in an effective way. A way to counteract confusion and provide structure is to create a tagline.
For example, I was working at an e-commerce start-up and I was tasked with solving the problem of users not completing their purchases. I simplified this into a hypothesis and said "by creating a seamless user experience around the ordering process sales will increase." This was then refined to give a tagline of "click-to-purchase" which helped teams to laser focus on the solution and bring clarity to the dilemma of users not completing their purchases.
It's easy to get tangled in the weeds when it comes to a tight scope. There are many questions, problems and variables that are intertwined pulling against each other not creating much room to decrease scope. Untangling these variables and focusing on the basic need will help to unravel confusion and further the ability to effectively manage scope.
No One Got Time for Perfectionism...Toss it!
Being asked your greatest weakness in an interview and saying you are a perfectionist can be perceived as boasting, but this is actually a real problem as a product manager. Obviously, there are certain products that are mission critical like life saving devices, railway systems, or electrical power systems. These need to be flushed out thoroughly because peoples lives are on the line.
All things considered, it's important to know when to let go instead of over investing into work. So when do you know when it's time to launch? This question can have different answers depending on the organization. I will discuss this in further detail in 'Product Readiness", but for now the below seems to be the baseline/standard approach for ready to launch requirements:
- Requirements met by stakeholders- Leadership, security, compliance, marketing, etc.
- Requirements met by Product manager- Basic MVP1 functionality of the product which can include performance and scalability.
- Product thoroughly tested- Engineers and PM (at the very least). If time prevails have external teams test.
- Approval of external teams- Legal, marketing, sales, communications. Marketing material and communications for pre/post launch.
- Product sign-off: Engineers, design, legal, marketing, sales, leadership and your line manager.
As a leader, it will be your job to know when timing is right. If a stakeholder or external team member pushes back on the launch date it's important to understand that development work and time has real cost attached to it—this is everyone's salaries. Also, the opportunity cost of delaying the launch as customer's won't be using the product so you won't receive 'real' feedback until the work is released.
Final Words 📖
Remember that your ideas are just hypothesis until validated by the user. So it's important to not build too much into a first release. Starting small (maybe in a beta program) to receive real feedback can stop the team from building unnecessary features and guide you towards work that can make the product a success.
Although, it's important to get your product in the hands of consumers don't take away from the quality of the product. Sometimes it's better to cut functionality than to cut polish. The seamless experience that UI offers is more valuable than added functionality that the user may not want or use.
Lastly, don't forget to stay humble and be brave. Not every idea you have will improve the product. Emotions can get the best of you especially when releasing a product that you feel isn't perfect. This is when you MUST lead as a PM and create a safe-to-fail culture that celebrates wins and opportunities. Encouraging and advocating for this type of culture will create a better outcome for your product.
Next Steps 🚀
- Minimum Viable Product
- Iterative Project Management Process, Tips, and Templates
- Hypothesis Driven Practices to build better features