Tuesday, October 28, 2014

A Look at Products vs Features

My thoughts on Products vs Features
Or how to think about developing products rather than features.
(Also published to LinkedIn)

Borrowed from marketoonist.com
 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

Tuesday, October 7, 2014

Get Active!

Having doing Product Management for many years I found myself recently in a bit of a slump - at some point I reached a threshold where what I was doing just wasn't very satisfying. This was due to several factors:
  1. Post-Release Blues - the "1.0" of my most recent responsibility had gone to market which is really exciting. All the months of creative energy expelled in a giant burst, which ultimately ended up being anti-climactic - to achieve an MVP the product was lacking in several key areas to really make it functional. These were the result of a lack of understanding regarding the real needs of the user - we had made some assumptions, and as usual when you make decisions based on guesses rather than real data, those assumptions led to a less-than-usable product.
  2. Post-Release Follow-up - So the next several months were spent bringing the product up to what is/was the actual MVP. This included bugs but mostly it was lack of processing functionality (not as in calculative capacity, but rather in business process management function). We've finally gotten the product to a point where it was relatively safe to release to the public, and more importantly to our internal business users.
  3. New Priorities - of course things changed during the overall process to release to 1.0 and these new changes (support for an entirely new conceptual product-line) also added complexity that mired our teams for several months (and it didn't help that the requirements changed several times before we got this right). Luckily the agile process allowed us to be nimble and adjust our product roadmap to bring these new features to the forefront. It did cause a bit of a stir company-wide as our roadmap and commitments changed. Tough to do this in a relatively heavy top-down managed company.
  4. Note Celebrating Small Successes - nothing like feeling like your behind to keep you from enjoying things that go right. We all need to keep things in perspective and it's often difficult to see the trees when you're in the middle of the Sequoia National Forest.
So in total, my overall morale had been low. So what to do about it? In my case I became more active in activities set to expand the mind - and no I'm not talking about mind-expanding drugs. I started to go to local industry meets (it's helpful if your company is part of the local tech scene - in Atlanta there's the Technology Association of Georgia (TAG) which is helpful as there are always meetings by various associations going on - I joined the Product Management association within TAG). But don't limit yourself there. I also joined the local ProductCamp and started to go to the yearly unconference and at some point will participate in presentation. But getting involved in those two groups was like having an appetizer during a nice meal - you want more! Besides the local, more formalized groups, look at MeetUp and what it has to offer. What to do?

My suggestion is to expand outside of your normal circles - start on the technology side and move outward - see where it goes. I have a firm belief that from a product management perspective, anything that we do to further a product should be first supported by good data. If you don't have data how do you know that what you're doing meets what the market wants, or through extrapolation, what the market could want (emerging or untapped markets)? Everything that we do as technologists should be supported by data. So what's more natural than to get involved in the local data groups? I joined both the Microsoft BI group and the Data Scientist ATL group - the former is a bit more on the technical application side while the latter is more about theory and the procedure/process of collection and filtering. Both are interesting in different ways and a byproduct is that you will meet people that may not be in your normal circles. I really enjoy both groups and they have expanded my horizons. The latter group is also very social - I think this is an important aspect of what we do as technologists that becomes lost in all the work we become saturated within - meeting people at a more casual level lets the mind explore new possibilities.

An example - during the last Data Science ATL meetup I met several new people - one was a consultant who really liked to connect people of similar mindsets to each other to promote technology and innovation; the second was a php UI developer (Not a group I normally associate with); the third was a data scientist. All three were co-mingling, having snacks and a couple of beers with discussions roving all over the place: work, technology, possibility, networking - you get the idea. Somehow I got into a discussion regarding SpaceX and what Elon Musk is doing in the private sector and this got things rolling into what new innovations along those lines were being explored here in Atlanta. The result was unobstructed idea flow, laughter and an expansion of awareness. It's also how the beginnings of an idea happen - often through casual conversation - you just need to find the right people to involve in those conversations.

Taking some of the thinking regarding these groups and what I found there, I started my own MeetUp group - this one around Socal Business application (meaning the application of social networking tools to the enterprise) - something that interests me. I've had one meetup so far with a little over half attending. It's a start and it gets things going - if nothing else it gets my own mind moving. Details about Atlanta Social Business Product Management. If you look at my last couple of posts you'll see reference to the MeetUp and what this topic is all about.

So where does this take you? I don't think it matters - what matters is getting your mind into new situations and possibilities so you aren't so buried in the day-to-day grind of achieving sprint goals. Step away from your desk occasionally and have a conversation with those in your office you don't normally interact with. Join your office leadership committee or volunteer to help plan office events. Do things to break up your normal activities so the job doesn't wear on you and you'll be glad you did - your employer will be too (as long as you don't do anything to get arrested!).

-- John