From Why to What
A product team’s guide to picking a fight
In a past article, I made the claim that you were better off building solutions, and not features.
There’s a delicate balance that we juggle throughout this process — anticipating as many challenges as we can upfront, while only addressing the ones that take us forward.
But I can’t hand off “Why” to a team of developers. So how do we make sure we’re only building a solution to the problem we set out to solve in the first place? Well… we can’t, not fully.
A Snowball
Time is at stake, that’s true, but building a solution to a problem we assume we’ll encounter can very easily snowball to even more waste — Up to the point whereby the general experience of using your product is degraded.
Having said that, working on something that may fail is by no means a waste of time, as long as you make a conscious effort to learn from the process.
What can I do about it?
Below are a number of methods that, from my experience, help drive you in the right direction:
YAGNI
YAGNI, or, “You Ain’t Gonna Need It” for example, is a principle of extreme programming (XP) that states a programmer should not add functionality until deemed absolutely necessary.
XP co-founder Ron Jeffries has written: “Always implement things when you actually need them, never when you just foresee that you need them. (Thanks Wikipedia!)
If you abstract this principle away from programming, which for me is quite easy as I’m clearly no developer, you’ll find a powerful principle; not only is it powerful, but it’s also simple, which as far as Principles go is far more important.
Outlined below are a few methods we could adopt to help mitigate the risks.
Test often
Working in a test driven manner to disprove/validate assumptions about our product is a great way to keep us focused on what’s really important.
Build prototypes as fast as you can, test them and then iterate.
Watch this excellent video from Google Ventures about working with research sprints.
Design with data
Each member of the product team has his/her own interests in mind. The designer wants to achieve pixel perfection, the developer wants it to perform well, the marketer wants it to convert etc…
Setting clear, measurable KPIs that the team agrees are a reflection of your product’s success are a great way to make sure you all focus on what’s important.
Edit: More on this in a future article, but in the meanwhile, check out this awesome talk by @sazzy.
Jobs to Be Done
Using the JTBD framework, with its terminology, interviews, timeline and Job Stories (while I’m still low on production-ready-experience with it) has proven to be incredibly effective at getting the team focused on the purest form of the problem at hand, and consequently eliminating waste.
Conclusion
We are a community of people who spend entire days thinking about building products, and how we can do it better. I honestly hope reading this has helped you, even a bit, to spend your time more effectively.
That’s it. It would mean the world to me if you could share your thoughts on this matter.
