SpongeBob taught me a lot as a kid. Sure, he taught us about imagination, entrepreneurship, and Texas, which was all very useful. But, if you look closer (as I have in recent years) you’ll notice that SpongeBob also teaches several important lessons about Product Management.
Elicit User Feedback Early and Often
It’s imperative that the product team elicit feedback early and often throughout the design and development processes.
The developers and their customers (whether end users or project stakeholders) may have different ideas of what the final product should be. This difference in expectations, aptly named the “Expectation Gap,” will continually grow as the product takes shape. By frequently eliciting feedback and aligning the expectations of both sides developers can shrink the expectation gap and deliver a final product without any surprises.
Moreover, even after extensive requirements elicitation, customers will often have hidden requirements that they don’t think to mention until seeing the product in various stages of design and development.
If the development team fails to elicit feedback often enough, they may find the product they built “belongs in the trash”.
Ensure Product Requirements are Documented and Complete
It is equally important to elicit as many product requirements as possible from all stakeholders before (and sometimes during) development. Even in an agile environment, requirements should still be sufficient to guide development and mitigate problems which may arise during the sprint. The majority of IT projects go over budget or fail outright; this is often due to missing or incorrect requirements.
Even a single missing requirement can render a product worthless, like a Krusty Krab pizza without a Diet Dr. Kelp.
Build a Solution to a Problem
As a product manager, it’s important to remember that you’re not just building a product; you’re building a solution to a problem. It’s tempting to start adding “cool” features to the product or to try to build a one-size-fits-all solution; however, this often results in a bloated product that doesn’t solve any one problem particularly well, and a runaway budget to top it all off. Instead, start with a problem you’d like to solve and ensure that each new feature is directly related to solving that problem.
For help on aligning features to solving business problems, see Business Objectives Models.
You may feel constrained by this disciplined approach, but by prioritizing features with respect to their importance in solving a business problem you ensure that your resulting software does its job exceedingly well. Additionally, this approach will help preserve your development dollars so the most important pieces can be completed on time and within budget.
If you’re wasting time, you’re wasting money… and that’s just sick.
– Eugene Krabs
To help get in the mindset of solving problems, think of some products or businesses you like and try asking yourself “which problems do these businesses solve for me?” rather than asking yourself, “what are they selling?”
