My thoughts on Products vs Features
Or how to think about developing products rather than features.
(Also published to LinkedIn)
In
the course of "usual" product development, we product managers ideally
work from the user outward - basically what problem are we trying to
solve and what's the fastest way to get there. Since we think of
problems in regards to users, personas and entities/actors, the solution
is often one that incorporates technology and heuristics ad a fairly
granular level. Think of this as feature fulfillment. What I've learned
over the course of the last decade is that this isn't enough. Too often
we develop something that is so specific, only to "refactor" or
otherwise redesign the software underpinnings at a later time due to
unanticipated discovery over time. We've all been there and done that
I'm sure, especially anyone involved in software development over time.
Instead, we should be thinking of solutions that have broader application, or at least open up the conversation towards reuse that could expand into a product. In classic development, we often approach things with the end-goal in mind. What's the MVP? How quickly can we get this into production, delighting the user or otherwise providing a feature solution. Subsequent development often introduces similar concepts and provides an avenue to "reuse the code" due to similarities. At this point, if your coding partners have some experience they may suggest a refactor and reuse which is good. What I'm suggesting is that we should try to lead with this idea and then do some analysis to decide whether we spend the time upfront in design or shelve broader product concept for quick delivery.
An example - you may have worked on an application that has a need to do some calculation such as an amortization calculator. You basically provide a utility to calculate interest and principle payments to determine how different loan lengths impact your monthly payment or time-to-complete the loan. The following year you have a different calculator needed in another area of the application that's similar so initially you may think to just copy the code for the second app. By the time you get to the third calculator needed, someone in dev says "hey maybe we should combine the apps and make a configurable solution that can be used anywhere" - which is a great idea, however now you face the task of absorbing the technical debt to rework everything.
Instead of "going the normal route" as described above, let's look at this from a product perspective. The problem you're trying to solve is the need to make some calculations via some utility available to the user. Doesn't that sound like something that's likely to be needed in more than one instance? Is something available that you can find that's inexpensively licensed as a plug in, rather than writing the code? If so, how much complexity to incorporate the component, etc. and how useful is it? Can it be applied to different types of calculations? Really, is it any good or just a hack? If we're doing our jobs as product managers we should be thinking along these lines and through the process of discovery and affinity comparison, decide if we can do a better job than what's available off-the-shelf and if so, that should suggest that there's probably an opportunity hidden there. We should also do some basic research and analysis on any potential opportunities so we aren't doing things in a whimsical manner. In my opinion, all of our product decisions should be based on data - otherwise we're just guessing.
So if you decide that there is indeed an opportunity, how to defend the additional up-front development cost? This is the tricky part - you can certainly over-engineer a "widget" - ask me sometime about building a super-configurable application that was so complex the adoption was very limited - there's a need to balance the planned intent against what's being executed at any given time. The start of all this should be a conversation with your devs, and in particular your architects, about the approach. If they know up-front that you're thinking about this new "widget" as a potential product, they will certainly build into the design some "hooks" so it can be flexible, and some baseline configuration that doesn't entail too much of an engineering effort. You have to get your team involved early and build some basic product planning before being involved in the execution of code. You also need to rein in some of those efforts so your guys aren't building a nuclear power plant when your trying to supply a battery.
Bottom line? Start thinking of what you're building as something more than simple components - start thinking of them as features of potentially stand-alone applications (only skinnied-down to solve a specific problem). Second, talk to your devs and discuss what you're thinking - you'll be surprised at what they can come up with. Invention is indeed the mother of necessity, but don't rely on only yourself as a guide to the approach.
-- John
Or how to think about developing products rather than features.
(Also published to LinkedIn)
Borrowed from marketoonist.com |
Instead, we should be thinking of solutions that have broader application, or at least open up the conversation towards reuse that could expand into a product. In classic development, we often approach things with the end-goal in mind. What's the MVP? How quickly can we get this into production, delighting the user or otherwise providing a feature solution. Subsequent development often introduces similar concepts and provides an avenue to "reuse the code" due to similarities. At this point, if your coding partners have some experience they may suggest a refactor and reuse which is good. What I'm suggesting is that we should try to lead with this idea and then do some analysis to decide whether we spend the time upfront in design or shelve broader product concept for quick delivery.
An example - you may have worked on an application that has a need to do some calculation such as an amortization calculator. You basically provide a utility to calculate interest and principle payments to determine how different loan lengths impact your monthly payment or time-to-complete the loan. The following year you have a different calculator needed in another area of the application that's similar so initially you may think to just copy the code for the second app. By the time you get to the third calculator needed, someone in dev says "hey maybe we should combine the apps and make a configurable solution that can be used anywhere" - which is a great idea, however now you face the task of absorbing the technical debt to rework everything.
Instead of "going the normal route" as described above, let's look at this from a product perspective. The problem you're trying to solve is the need to make some calculations via some utility available to the user. Doesn't that sound like something that's likely to be needed in more than one instance? Is something available that you can find that's inexpensively licensed as a plug in, rather than writing the code? If so, how much complexity to incorporate the component, etc. and how useful is it? Can it be applied to different types of calculations? Really, is it any good or just a hack? If we're doing our jobs as product managers we should be thinking along these lines and through the process of discovery and affinity comparison, decide if we can do a better job than what's available off-the-shelf and if so, that should suggest that there's probably an opportunity hidden there. We should also do some basic research and analysis on any potential opportunities so we aren't doing things in a whimsical manner. In my opinion, all of our product decisions should be based on data - otherwise we're just guessing.
So if you decide that there is indeed an opportunity, how to defend the additional up-front development cost? This is the tricky part - you can certainly over-engineer a "widget" - ask me sometime about building a super-configurable application that was so complex the adoption was very limited - there's a need to balance the planned intent against what's being executed at any given time. The start of all this should be a conversation with your devs, and in particular your architects, about the approach. If they know up-front that you're thinking about this new "widget" as a potential product, they will certainly build into the design some "hooks" so it can be flexible, and some baseline configuration that doesn't entail too much of an engineering effort. You have to get your team involved early and build some basic product planning before being involved in the execution of code. You also need to rein in some of those efforts so your guys aren't building a nuclear power plant when your trying to supply a battery.
Bottom line? Start thinking of what you're building as something more than simple components - start thinking of them as features of potentially stand-alone applications (only skinnied-down to solve a specific problem). Second, talk to your devs and discuss what you're thinking - you'll be surprised at what they can come up with. Invention is indeed the mother of necessity, but don't rely on only yourself as a guide to the approach.
-- John
No comments:
Post a Comment