Product Management Soft Skills

You old softy...

As a preface to this, I was asked recently about how I had come up with a solution to a problem and I started explaining my thought process and the rationale behind my recommendations. Much of my explanation was around the use of insight and experience to dissuade or direct the conversation to a mutually beneficial conclusion, somehow getting my way (which I considered the best solution) rather than what the client was specifically asking to be done. I was asked "How do I learn how to do that?" This led me into thinking about soft skills and how they can impact a project and the success of the product manager. It seems a lot of hiring managers put great emphasis into experience and degrees and yes, these can go a long way towards your career goals, as does training (for instance, I'd recommend to any aspiring product manager to take the CSPO course). The more environments, the more applications, the more businesses you've had the fortune of working with and within, the better you'll be able to use those experiences and apply them to product management. However that is only part of the story. I think the traits best explored for improvement have to do with soft skills that really amount to a single concept - that's how well you develop relationships. In general I'm referring to the tool kit everyone carries around and uses whether you are aware of it or not, that enables you to be effective to and with those around you. I'll break these down into several categories: communication, empathy, context, data, shared ideas and goals, passion, and trust.

In nearly all product management job listings there's a common element that's generally wrapped up in a couple of lines that have to do with effective communication. As a product management professional, our job is really to delight the customer or consumer with what we are building - this applies to software, hardware or just about anything else. The first soft skill that is essential to being good at our job, is having the ability to translate what we hear, develop an understanding, and be able to retell what you have heard in your own words. This, combined with thoughtful conversation that includes back-and-forth questioning, leads to a shared understanding and allows you to further relate your understanding effectively to those on your team responsible for executing the objective, in my case, great and usable application software. From a high level, we call these requirements and some of the artifacts may turn into SOWs, functional requirements, epics and user stories - whatever works for your group. Everything begins with conversation and some type of validation process to develop a shared understanding, which you will do multiple times through the life of a project, whether small or large. In regards to communication, I believe it's more important to develop the skill of listening rather than speaking - it's difficult to understand what's being said if you spend all your time talking. The follow-up skill is to ask good questions. I like the adage, "There are no stupid questions" - you should take this to heart and make no assumptions. If you are constantly fielding questions from development and having to pass them along to a business contact for clarification, then you have probably not asked enough questions at project inception, nor do you fully understand the project. It's OK for this to happen if you have little context (like in the very beginning or if you are new to product management), however it's part of your job to have this context beforehand so you can anticipate those questions. More on this later.

The next soft skill to develop is empathy. A fairly generic description is to place yourself in the shoes of those asking for the feature or those experiencing the problem. Until you fully understand what is being experienced, it's really difficult to create a good solution. I think in general we in software development spend too much time coming up with the next new, cool feature and not enough time understanding what is useful or needed. We tend to take for granted those that are using the software we create on a day-to-day basis - the proof is all around us - how many times have you heard of some application releasing something that's held in so little regard it seriously impacts the company negatively? Sometimes we try to make things too complicated and this kills adoption. Other times we just plain miss the mark by providing something that no one really cares about. We need to use empathy to understand how our products are used and to access how important features are to our users. This will help us in developing good behavior-driven design in our products and we need to be able to provide this as context to our teams. Empathy also is very important when interacting with our team members. You need to understand what they are doing to some extent, or more importantly you need to be able to detect when someone is frustrated, either with a task or in trying to execute against their understanding of a user story or requirement. Have you ever had a story fail over to the next sprint over-and-over, greatly exceeding the original point estimate? Have you tried to empathize with those executing the story to attempt an understanding of why the story isn't done, or do you start complaining? It's through empathy that we become better understanding, and consequently, better at delivery.

I'll go on to context next, as I've already mentioned it in the two preceding soft skills on my list. Understanding how to use context is important as it provides the environment from which you will become the most successful. So how is this a soft skill? I think we take for granted when writing requirements how important context is to your team members. Often when I get a question like "why do they need this?" or "what are they trying to accomplish" it identifies a contextual problem - your team should already understand where a user story or requirement is going prior to the start of coding. To become skillful with context, a product manager needs to fully understand why the requirement exists. To understand why it exists, one needs to comprehend what problem or opportunity is being solved. Just as a good book needs a setting to establish the framework of a story, a good requirement needs context to fill in the gaps so there is a common understanding of what underlies the requirement. As a soft skill, to be effective the product manager needs to both understand the context and relate it meaningly to the team. It's this latter bit that identifies the execution of context as a skill and it's something that's often missing when working with a team. To me, being able to use affinity to something that's already been built, or using common analogies to illustrate concepts is very important. These may be supplemented with process diagrams but for me, white boards are essential to both describe the action, provide context and to answer questions - they're also a great way to identify gaps or issues.

How is data a soft skill? It's not in itself, rather it's a reference that needs to be recognized as important for many reasons. For those of you who have read my blog or other posts, you'll know I harp on data all the time, and for a reason. As a soft skill, you must recognize the importance of data, develop methods of acquiring it; and engender skills to interpret, refine, filter and express that data into a useful outcome. What I like the best about data is that if you know and understand it, you will be able to influence everything. As a tool, data is more of a crowbar that allows you to intersect with existing efforts, interject new thinking when needed and break heads as a last resort. Noting wins an argument faster and more completely than having the data on hand to support your position. If you're ever done any debating, you'll know that having quotable references provides huge advantages and can deter long and heated arguments - the same goes with having data on hand and some analysis on how it impacts your projects. If you live by the need to have data for your decisions prior to pitching them, this tool can take you a long way in executing your product vision successfully.

Which brings us to the next soft skill, being able to foster an environment of shared ideas and goals. You might think of this as teamwork, but I don't consider teamwork a soft skill so much as how a good product manager provides insight to contribute to the ideal team. So from my perspective, teamwork itself isn't a soft skill, but rather having an ability to instill a common goal in the team so everyone is working towards the same outcome. Many of the artifacts around scrum are there to get the team working together within a sprint - what the product manager can bring to the table is an alignment from overall corporate goals, to business unit goals, to team goals and finally to sprint and release goals. The good product manager constantly reinforces those goals throughout the process and helps to redirect the team's thinking to achieving those goals throughout the development process. If you've ever worked in a very efficient team, you'll know what I'm referring to here - it's often displayed when someone on the team asks the question "How does this fit into the overall effort?" or "This seams contrary to the drive for revenue" or something similar. The question itself isn't as important to what it implies - that someone is thinking about how everything fits together instead of blindly coding specifically what is being asked to be built. Once again, there are no stupid questions...

It seems we all want passion in our lives - I think as a soft skill it's more about how that passion is expressed and how it communicates to others on the team and to your customers. At the deepest level, as a product manager you should be passionate about what you are doing - if you're not, then why are you doing it? I think many would disqualify passion as a soft skill, and I'm sure all of us have encountered people who were so passionate that they were actually detrimental to a project. The quality or soft skill we want to develop is to make use of that passion to reinforce the team, the project, and in general use it to focus and influence all participants into aligning into a common goal - success and enthusiasm in creating great products! Just as we use the other soft skills as parts of the product management tool kit, passion can be used to either bludgeon or enhance a team. As such it's both a sledgehammer and a micro-screwdriver (but typically it's the former and not the latter). The difficult part is learning when to let the passion out-of-the-bag and when to save it for later - for instance, using it at the wrong time can lead to confusion and accusations of "emotional problems" (nothing like being accused of bipolar disorder!) - instead I think we should use that passion as a general enthusiasm of the project and team; and save real outburst for when they can be the most effective. We also must be very careful not to get carried away and allow it to have the opposite effect (what happens when it's used inappropriately).

The final soft skill and perhaps it's more an outcome of all the rest than a skill itself, is trust. Everything that we do as product management professionals leads to building relationships. To have good relationships, each party needs to trust the other. I often hear about transparency, communication, face-to-face meetings, etc to improve the design and build process, but really all of these are vehicles for the same thing - building trust. It's much easier to empathize with team members on a project when you have met them personally. When you have the trust of your business, your customers and your team, there's very little you can't accomplish. It's even possible to come in on time and under budget! So how do you get this trust and how can it be leveraged? if you think back to how I began with the idea of relationships, it's something that's difficult to quantify, but we all tend to have some idea about how well things are going. When things are going extremely well, the trust level tends to be very high. The opposite it true when things are going poorly. When you are questioned regarding a product decision, it's usually because there is no trust or that trust is in question. This becomes a culmination of all the other soft skills - when you use all other tools effectively trust is enhanced. And also the opposite is true - if you fall short on one or more of these soft skills, if you have already developed a high degree of trust, then much of that lack is forgiven.

That's about it for me - understand I'm not saying that these are the only qualities or soft tools that we need to be successful, I'm sure there are many more. These are just those that I've thought about during the last 30 minutes or so.

-- John

Revolution vs Evolution

I've recently been in a few discussions with colleagues about software innovation and how it relates to product management so I thought I would share a few thoughts. We always talk about opportunity, and frankly, we usually use it in a context to defend or soften a product decision to an end user (aka client). In this way we use words like "opportunity" to define a problem that needs fixing - since many of us bill for the work, the term "opportunity" equates to making more money, at least to a consulting company; and the use of the term "opportunity" is much more palatable than "problem." Instead we should identify problems as problems and spend our time working through solutions and really, isn't "solution" a better term than "opportunity"? In any case, I digress, as the topic I want to explore is one of innovation.


What got me thinking about this is an encounter I had earlier this year with a process improvement group. This is the scenario - I'm working within a project to rewrite existing software using new technology and better design principles. Most of the requirements were derived from interviews with the management teams using the existing software (they in turn presumably worked with their teams to come up with innovations and improvements). Fairly straight-forward, right? We then took those requirements and began exploring implementation converting the requirements into epics and user stories, to get the conversation going with our team, derive executable bits and present them back to the business users as we move from bits, to MVP, to production release and consumption. We take a very agile approach to software development so the first hurdle was to get our business users to adapt to this practice - not an easy task. Our BUs tend to throw everything into the requirements and their initial expectation was that everything listed would get done - which made it very difficult to get things through UAT, even when we constantly explained that it was a planned cycle of development moving from simple to complex. In their minds, "working software" meant that everything they wanted on the requirements was done, to be able to define the software as working. Once again I digress, but this time to help provide some context.

In actuality, there's an inherent problem with this requirements gathering method. First, the innovations asked for by the business user usually relate to the existing software platform and amount for the most part to tweaks or small process improvements. Second, when those requirements come through the management filter they tend to be broad-stroke in some regards, and myopic in others (depending on what the manager perceives as important). Third, the methods that the business user is defining in requirements are usually the same as the original software without thinking about how the entire application could be improved by changing the underlying software method - what I mean by that, is when you have staff trained to use software and they are used to that software, it's hard for them to think about an entirely new methodology that's outside of that experience and context. So to continue my story, some of the things we introduced in the rewrite had to do with using an off-the-shelf BPM engine. Our thinking was "why reinvent the wheel when there are already so many companies out there who have figured it out?" So this became the first point of contention - even through a BPM package may satisfy the baseline requirements, there are usually some fairly rigid rules within a fixed methodology that are required by the software itself. It's a tradeoff - you get better accuracy and many of the bells-and-whistles you're looking for, but to take advantage of them you need to conform to the methodology designed within the software. Once implemented, the next challenge was to get our business users to understand that the methods have changed - the outcomes are the same, but by using something more standardized, it will be easier and better to use the same software to do similar tasks. This change is rather disruptive, produces a lot of user angst and confuses people, who are still used to using the original, legacy software.

So around the time we first got our users used to the changes with the introduction of the BPM technology, we were introduced to a new process improvement group. Seeing this as an "opportunity" - the group was brought in to look at the existing methods and suggest improvements that could be incorporated into the newly designed software. This included analysts actually sitting down with the business users and observing how they use the software. We welcomed the additional resources and hoped that a few "magic bullets" would be identified to really make our newly rewritten software fantastic, hopefully saving money and time by identifying process improvements through the application of technology. So now, we're getting to the crux of my article.

The report that was delivered was interesting, not in all the suggested changes and aggregate analysis defending changes to the overall workflow, but in that it copied almost requirement-by-requirement what we had already defined and planned in the rewrite. It basically validated what we already knew and made the same improvement suggestions that we had already planned. What we received was evolution, rather than the hoped for revolution. And please don't think that I'm diminishing the importance of what the process improvement group did - it's nice to have validation in what we are doing and have planned and there's certainly value in that. I think that as a group we had much greater hopes and that our expectations were unrealistic. I also think that in our world of software development we spend a lot of time trying to improve things rather than searching for new solutions - that outside-of-the-box solution that's so new it can redefine what we are doing and how we are doing it. Not to say there's no value in evolution. One of the easiest things to defend are improvements that cut the bottom line - even small process improvements can do this and the accumulated savings can be quite significant.

So what is better? In my opinion, revolution is thinking about a problem and coming up with a solution that is so novel it doesn't fit within the original problem statement. The downside is that it can be very risky. And no, the ideas don't often happen overnight. Evolution on the other hand, involves small, incremental changes and has less risk, but when that's what you rely upon, you could get trumped by a new market contender with revolutionary ideas. I really think we should use both methods but in general try to think in revolutionary terms - more of a mindset than a strict method. We should embrace the good ideas backed by real data, and defer on ideas that offer little to the bottom line that have no data to support them.

How I long for a time when I receive information that is filtered for relevancy (important to me and customized for my needs), from several sources, all in one place using a single sortable and filterable delivery mechanism. There's been a metamorphosis of thinking when it comes to communication that started with emails, went to the use of distribution lists, forums, communities, wikis and now messaging aggregation with software like Slack. This last example is something transformative that's been happening for several years and is only now beginning to get some attention outside of software developers. You would think that this is an example of evolution, but when it moves outside of the development word it becomes revolution.

Quantified and Qualifed Data

I'm back on the Data bandwagon and please excuse me for being persistent - if you read my last post, I made some statements about the importance of data. I then listed some ways we, as product management, should assemble data to support our product actions. I'm continuing with some thoughts that have bearing that I was remiss in pointing out the last time. If you read that last post, I made some assumptions that you can infer regarding the data itself, but wasn't very explicit so this is a bit of a clarification. What I called Data that last time should have been called "Quantified and Qualified Data" - I'll explain.

Monday night (2014.11.17) I attended the Atlanta Mobile Developer's Group meeting in Buckhead (this was at Alliance One and hosted by eHire). The presentation was called "The Tau of Mau: How to turn meaningless app downloads into engaged users" provided by Jeff Steinke. The presentation was one of the better I've attended this year - in this case "MAU" is Monthly Acquired Users and refers to a trend in the mobile industry to measure success by registrations. He used a graph bearing from 0 to 700K that hockey-sticks over a period of several months and began with little explanation to see if, based on that little bit of information and making the assumption that the room was full of potential investors, would we be willing to invest.

Without giving too much more of his presentation away and to get to the point of today's post, several slides in Jeff talked about how data should be both Quantified AND Qualified and how that first exercise put all the reliance on the quantity, and not on how qualified the data was. For mobile app users (and really for most B2C web users), downloads mean very little without engagement. For one of Jeff's company's (Less Meeting), he listed three things that allowed them to know a better picture of success: download (registration); completion of a short tutorial; and finally the use of the app to schedule a meeting. The talk itself boiled down to engagement and the definition of engagement (for most it's convergence - if the user isn't using your product, then a free download has little meaning). Jeff had done enough analysis to determine that if their new user accomplishes the three things on his list, there was a high degree of certainty that the newbie would become a real, paying customer. Back to the initial example used by Jeff to illustrate unqualified data, the company had a lot of MAU but very little actually ongoing engagement. Hard to monetize users if your application is a "one trick pony."

From my own personal experience, I've worked on several applications where the project decision was made for me and ultimately that decision was flawed. The problem is in looking at the raw data and not applying some sound reasoning to filter the data into something that's qualified. In the earlier days of the web there was a lot of emphasis on getting application registrations - this was based on an old-school thought that when people buy software they have skin-in-the-game and as a result they become users. The issue with that assumption is that the web changed the paradigm - all those early companies (most now defunct) based their logic on sheer numbers, and it was relatively easy to get funding (everyone wanted to invest in the next new start up and become an internet-millionaire!). Saying you had millions of "users" (meaning registrations) sounds awesome to investors who would hand-over-money just for an opportunity, without any sound reasoning behind what would power the monetization of those users. When the Dot-bomb dropped and there was a rush to convert all those free registrants to paying customers, the companies fell like dominoes. The analysis was flawed.

The other metric that often used to sell-a-company is number of site visits. The argument is that if you have a lot of visitors, you can always build a revenue model of page views and click-throughs. As someone who has also worked in this type of environment, this can also become a flawed statistic. When you look at the actual number of views you need to make any appreciable money from this model, you're not making much until you get into the 100s of millions. The corresponding likelihood of a click-through is likewise a flawed statistic. If the keywords driving those ads aren't relevant to the user (meaning things have to align just-right - user type, application type, paid-for-words and the gods!) the actual revenue gains are significant as single-instances, but flawed as a sum. Also, these types of campaigns are cyclical in nature so they can rarely be relied upon (one exception is to create a "key accounts" model where you have broad-spectrum advertisers who already have established brands). A technique to help you qualify these numbers is to tag pages to ensure that the user stays on the long enough to actually see the ads placed. Another is to use SEM to aid in placing inbound, specialty pages, which tends to have a synergistic affect on organic search.

So what else can you do? I think that using experts to help you decide can go a long way towards qualifying the data (I'm a fan of Data Science). I also think it's very important to use both the experience of your team and the information you garner from existing customers, to determine how that data rolls-up into something that can be used. If you look at something and don't understand it, re-examine the data to see if it fits some patterns or anti-patterns that make sense. Another idea is to leverage your network of technical experts - I'm sure we all know and have worked with professionals who have "the eye" in regards to gaining insight into the data. Ask lots of questions, gather your data and make sense of it.  Put monetary figures against what's happening and compare it to what you know and possibly don't know. Strive for understanding, and make the data work for you.

More information regarding the Atlanta Mobile Developer's Group: http://www.meetup.com/Atlanta-Mobile-Developers-Group/

Jeff Steinke's blog: http://www.jeffsteinke.com/

(also published on LinkedIn)

Good Product Management is Based on Good Data

I harp on this all the time and I'm sure my colleagues are tired of me saying it - but I'm of the firm opinion that we should DO NOTHING in regards to product management or product development, without the data to support our decisions. The foundation of any change is underpinned by data to support that change - whimsical changes or even changes supported by some perceived need, mean very little without supported analytics. Foregoing the due diligence, even for small changes can not only be detrimental to the application but can also ultimately impact your company's bottom-line. You do not want to be in the position of defending your actions, even if they seem innocuous, against a product backlog that has real calculated ROI.

Even Dev Prospecting (the idea that sometimes we need to push a change that could garner new business or customers with some nebulous "maybe" result through innovation) should have a minimal data construct projecting what may come from doing so. For this I look at data models in parallel or similar affinity vertical markets.

If you aren't paying attention to the data, making some effort to understand the trends, and have the ability to filter the noise and make some decent projections based on what you see, you're doing more harm than good. So as a Product Manager, what can you do to get this data?

Research: Public Searches. The first avenue for any good product manager is to start doing some searches online using probably keywords. I think most product managers already have some ability at finding public information - it's a skill one develops over the years and is a good starting point for just about any knowledge gathering. Google is your friend, but this is only a starting point. I'd suggest you start brainstorming and as you broaden your searches, additional keywords will suggest themselves in the results you find. Make sure you note what you find but stay relatively focused using the additional words as possibilities as they can get you really distracted (ask me how I know?).

Research: Examine Your Internal Data. The second tool in every product managers tool-kit is internal data. Most of us have applications that have been running for several years and the data is sitting there for the grabbing. Look at the data points you have and see if there's information there that can be used for modeling or to suggest avenues that support your case. Just be careful, especially if you're forecasting to take this data with a grain-of-salt. Using existing data works great to support cost savings; it's much more dangerous to use it to support revenue opportunities.

Research: Use Your Existing Customer Pool. It's always blown-my-mind when I've come to a company and realized that there is almost no interaction with the existing customers, beyond simple support and account management. If you have enough data to identify problem areas in your application via support calls and emails, what's more useful than to reach out to your customers and start a conversation. Begin with what they like, move to what they don't like, then start suggesting things you'd like to do. The information you receive can be quite compelling and leading you to paths making good application decisions.

Research: Use Your Existing Sales and Support Pool. As above, we often receive feedback for what's wrong or bad with what we are doing from an application level. What's harder is to get a sense of what really needs to be changed or fixed. Use data as the foundation, then interviews with your coworkers to gauge what will have the most impact - you'll often be surprised at what you find out and once again, these are leads that can direct you towards real innovation. I love getting sales figures and using the information to defend a case for doing something, or even better, against doing something being driven by someone with influence but no clear understanding of what's needed.

Big Data and DataScience. The last and this is something that I'm a big fan of - hopefully your company has embraced DataScience and hired a good python developer to parse through your tables. It's amazing what can be discovered by trending data and looking for graph-outliers or anti-trends. As product managers, we need to better understand how this last tool can be used effectively, to support our case when making product decisions.
I think most product managers understand all of this, if at a very subconscious level. At minimum, keep your mind open and don't simply disqualify ideas being promoted by your coworkers - I know that we're all busy and that this is easy to do, but your do yourself an injustice and really exhibit a lack of respect for those you depend upon the most.

"I get it...I get it"...

-- John

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

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

The Argument for Social Business

There's currently quite a bit of buzz around the term Social Business - especially around HCM (Human Capital Management) so I thought I would address the term. I think what makes it a bit confusing is that the term is already used as defined by Muhammad Yunis in 2009 in his books "Creating a world without poverty - Social Business and the future of capitalism" and "Building Social Business -  The new kind of capitalism that serves humanity's most pressing needs." The books in general are about changing business prime-directives from maximizing profits to financial self-sustainment and re-investment. This is much different from the term Social Business used to describe a socialization trend happening in businesses that refers to the use of social tools in everyday business practices.

A better term might be "Collaborative Business" and in general refers to the use of some of those abstract constructs used in social networks but applied at the business level. Most of these constructs involve the "group think" concepts of shared posts, transparent threading of messages/emails/posts, the aggregation of interactivity across multiple tools and the community aspect of collaboration as embraced by businesses, at minimum internally and ultimately with external clients and experts. Ideally Social Business incorporates the various communities involved with the business and introduces a higher degree of interaction between the communities. The stress is on engagement and the result can be measurable depending on how things are defined (aligning the goals of the business with the efforts involved in sharing information). HCM has begun adopting some of these constructs, especially for internal communication but I believe to be effective these tools should be implemented beyond the enterprise - however it's still a good first step at implementation.

IBM has done a rather remarkable job introducing the concept into it's core communication - much of this came about through a corporate initiative to allow its employees to blog articles to help disseminate information which then lead to their hosting both internal and external blogs - this was followed up by the extension of the old Lotus Notes into the current Domino product. I recently attended a TAG Social Society event (and if you haven't joined TAG - the Technology Association of Georgia, then this single group may make it worth while) that had the topic What Will My Email Look Like “Tomorrow”? (it was actually a combined event of separate TAG groups but the presentations were mostly around Social Business). Louis Richardson from IBM was the keynote - he started out with the the quote "Email is where messages end up to die" and spoke about the relative waste of using email to communicate, especially between a group trying to get consensus on a decision - his example had 6 people in it who all had to copy the entire group every time a comment was made. By the time several people commented (and some copied as yet other interested parties) there were quite a few emails in total (I believe he said the average is 150 emails to make one decision). He then referenced the way Domino addresses the problem - I won't go into detail but if you're really interested you may want to look up the feature description.

I'm using the IBM and the TAG Social Society reference above to illustrate my point - there are many thinking about the future of communication and collaboration and how it will be addressed by business, especially enterprise business. Why all the interest? If you look at the demographics, particularly of the Millennials and post Millennials that are making their way into business, you'll understand that this latest generation interacts differently with information than most of the "gray hairs" currently controlling business. This new group is used to multitasking using a variety of electronic devices, combining messaging, video, text-in-email, social media - you name it and they use it, often all at once. It's been observed that the group in general has become "wired" differently in the way they think - with information coming into the funnel (so to speak) in multiple work streams. The biggest change is the way information is collated by multiple participants into threads (the advantage is that information is shared to a larger group without multiple posts like in the email example provided by L. Richardson above).

Think about being a Millennial and being used to this work stream way of thinking, then hitting the plodding methods traditionally (well, at least the last 20 years) used by business where email is king - I can imagine the frustration and lack of enablement - and this may explain why companies who have adopted a more collaborative way of communicating using social tools have become so successful - Google is a good example. It might also indicate why so much of the talent pool is moving towards these "hot" companies (yeah you get free lunches and you always hear about the company culture - but is that enough?). My theory is that if we don't provide a communicative atmosphere of collaborative tools we aren't just missing the boat, we're basically given a paddle and told to make the best of it.

That that end, I think that the beginnings of the solution has already been adopted by technology teams (they tend to be the first to adopt good ideas) in most software development shops through the use of collaboration tools like Campfire and github. Many of the tools and ceremonies have also been adopted by the Agile and scrum shops to improve team communication - and it works! so I've pitched the idea to those I know who facilitate the agile/scrum model. To further examine how Social Business might be implemented, I've created a new MeetUp group called Atlanta Social Business Product Management (yeah it's obnoxious but I couldn't think of anything that had more zing). Please join if you're interested.