Document a full Year in the Life of a Product Manager

In a dauntless attempt to answer the near ubiquitous question, "What does a Product Manager do?", I decided to dedicate an entire year to recording and sharing my own journey down the product path.

I have had hundreds of conversations about the PM role, about this particular career path, and about the product development craft itself.  There is one topic that still dominates these discussions: what does it actually mean to be a Product Manager? I have collected several, almost stock responses over the years and readily share the one that best matches the other party's relative interest level.

For example, I was once asked by a colleague who had been practicing in the role for a little more than a year, "How do I even know if I'm actually doing product management?" Up to that point, I had never considered that an active PM might question whether they were really doing it right! After a bit more discussion, we agreed that an easy confidence test for an uncertain PM would be to provide affirmative answers to these 3 simple questions:

1. Are you regularly shipping your product?
2. Are your target users really using your product?
3. Are customers paying for your product?

I am not suggesting that we cracked the code here. Anyone who has been in this role will attest that it is not that simple. While we are all ultimately working toward those same goals, our methods can vary widely, even within the software/digital product space. So, where do we go to dig deeper into understanding that complexity?

Over the past few years, I have seen a real surge in the availability of authoritative resources that PMs can now access to help hone their craft. Many of these resources fall into the "How To" category, offering prescriptive approaches to addressing product-specific challenges. I set out to create something different.

What drove this decision

Even after having created software products for more than a decade, I don't believe that I can speak authoritatively on many product-related topics. But in my role as the head Product guy at this B2B software company, I have plenty of material to share with my peers and I can now confidently contribute some insights to what some have called our "often ambiguous discipline of product management".

It has been almost 20 years since I had regularly authored anything formal for an external, professional audience but I was up for a good challenge. I subscribe to the credo of pushing yourself outside of your comfort zone, to doing things that intimidate you at first. By committing to publishing 50+ articles in a single year, I was certainly going to do that. Plus, there was a good chance that I would become a gooder writer along the way.

What was most important for me, however, was creating a unique resource for other PMs who are going through the same challenges in their own jobs. I have discovered that people find great comfort in hearing that their peers have and are also struggling with the same problems that they have. Sometimes an honest report from a colleague can renew self-assurance and even inspire us to do better.

The decision: Contribute to the growing body of knowledge by sharing weekly accounts of my on-the-job experiences as the Head of Product for a late stage startup.

As far as I can tell, this is unprecedented in our field. As of this writing, I still haven't found anything comparable although some folks have published a handful of day-in-the-life pieces. Here's a few that stand out:

• A Day in the Life: Product Manager at Microsoft by Melanie Danko, published December 6, 2012 on Bloomberg site
• So, What Do You Actually Do As A Product Manager? by Catherine Shyu, published Feb 5, 2014 on Medium
• A good thread on Quora with several contributors dating back to 2010

I didn't have any year-long examples that I could follow but I was eager to plow forward anyway. I started in early January 2015 with no real audience. I had no Twitter followers, no email list, and no subscribers to this website. I started with a blank (blog) page and my atrophied writing muscles and dove right in. As I saw it at the time, there was very little risk and only upside (said the 3-time entrepreneur:-)

Plan of attack

I titled my new blog PM Decisions with the intention of using each post to document a different product decision I had made. This is the final article in the 52-week exercise but only the fourth that isn't directly tied to an actual decision I made while working at this company. At the outset, I would never have guessed that there would have been sufficient topics for me to produce a full year's worth of non-overlapping content.

I can't take much credit for the frenetic work environment that offered all these article opportunities but I do think the weekly journal format I chose was pivotal to the sustainability of the whole initiative. I wrote each article as if it were my own Captain's Log but I found that the diary approach was equally helpful as a narrative for aspiring and practicing Product Managers.

Highlight a single decision in each article

Toward the end of each week, I would find a particular activity that stood out from rest of the normal PM routine. I would qualify each potential topic by considering its relative importance to other Product Managers (my intended audience) and also how well I could decompose the elements to fit my own article template.

By focusing on one product decision at a time, I was able to go deeper into each particular topic, identifying constituents and stakeholders who were pushing for or were affected by the decision, and providing the specific steps I took in executing the decision.

I did my best to sanitize each story to avoid exposing sensitive details while still providing sufficient background information about my decision.

Create an article template for consistent storytelling

One of the best moves I made was landing on a common format for each article. I spent about 4 hours writing and publishing each article, always spread out over multiple days, but I would never have succeeded if not for this article template. It was much easier for me to flow the text, quotes, and images through each of the predefined sections in the template and in the end, I'm still convinced it is a good arrangement for documenting key decisions.

Thoroughly cover each decision

I used the following sections in the template to help me organize my thoughts:

• The article title offered a one-line summary of the actual product decision, making it easy for readers to scan over what would eventually become a large collection of content.
• The opening statement was specifically worded in the format "because of this...I decided to..." to provide context around the decision so that in article listings, the reader would have more information about whether the article would be relevant or not. I also included this statement in the article digest that was used for RSS feeds, email newsletters, and for creating smaller collections on the website.
• I followed the opening statement with a few paragraphs that tied that week's particular decision to a broader product management topic
• The next section in the template titled, What drove this decision is where I explained my motivation. This was often my favorite part to write because I was used the space to vent somewhat and occasionally, even climb up on my soapbox. I wanted to explain the reasons behind each of my decisions and justify those reasons both to the reader and also to myself. Sometimes, I approached this section as if I were prompting the reader, "would you have done things differently if you had been in my shoes?"
• After formally declaring and explaining the decision itself, I stepped through the actions I took in making the decision. I never meant to prescribe a repeatable solution and I didn't mean to suggest that my approach was the right one. I simply offered my plan of attack at the time, thinking it would be useful to the reader to see one person's approach.

The final section was called the impact, as in, the impact of my decision. Looking back over the collection of articles, I would admit that I mostly failed here. Others have also confirmed that the articles would typically start strong but would ultimately fizzle out toward the end.

Part of me would like to attribute that to the notion that you can't really measure the impact of a decision so close to making it. That it was too soon to appreciate or even understand the effect well enough to discuss it in the same week. I could just as easily blame it on running out of steam each week (did I mention this was an exhausting exercise?) Perhaps there is still an opportunity to go back to some of the articles and provide an updated postmortem.

Experiment with format, layout, and outreach

I could say that it's just my nature as a PM to tinker, to hypothesize and validate assumptions. And it is true that throughout the year, I tried some different things with my writing to see if I could improve my results. But in the end, I put most of the effort into just organizing my thoughts and capturing the words.

I mentioned that, up to this point, I had not been an active writer and even less of an online, social idea promoter. The latter made it even more challenging as I struggled with finding and attracting an audience. With some help from nearby experts, I eventually got the knack of publishing via Twitter (@theproductpath) and Linkedin but never went beyond that. Believe me when I say that I am happy with those results. Some early visibility on social channels is welcome of course but I had always set my sights on producing a collection with a longer shelf life.

I quickly learned from readers that I was good at producing tl;dr material

The lengthy article format was another strain. I quickly learned from readers that I was good at producing tl;dr material and that my weak attempts to call out specific points with quotes or bold text weren't really helping. I tried including more images and charts to break up the text but ultimately I was asking a lot from the reader.

I have recently given some thought to creating true digests for some or all of the articles and re-publishing the content in a way that would be more consumable for other Product Managers.

The impact

All in all, this has been a tremendous year. Even if my year-in-the-life series is not a first of its kind for product people, it was certainly an achievement for me. I improved as a writer, if only slightly, and now I have a unique body of work that makes for one heck of a conversation starter. In fact, I have made quite a few new product friends just from the word of mouth buzz around my efforts.

One of the unexpected, but positive outcomes of an exercise like this is that it became much easier to interview PM candidates at my company. I found that I could simply tell them, "if you want to know what its like to work here, just read this!"

So as I close out this particular series, I want to thank everyone who encouraged me. Even though I didn't quite acquire the fan base that I might have once dreamed of, I did get the support I needed. I will continue to write on product-related topics here on theProductPath and have already found the next intimidating activity to tackle.

Balance give and take, yes and no, push and pull with products

In a week that seemed to bring every form of product choice a PM can encounter, I decided to exhibit strong product leadership on every front.

Most Product Managers are continuously making choices about what goes into the product and what stays out. We use tools like the product roadmap to break down and convey these decisions over appropriately-sized release cycles.

Senior PMs also have to make choices about which Product Manager works on what parts of the overall puzzle and how best to coordinate dependencies across all the pieces to deliver the larger solution in a timely way.

We make difficult choices about what we feel comfortable promising to the Sales and Marketing teams who are busy prospecting for future customers that will bring in new revenue.

And Product Managers have to make critical choices about how to balance the perfectly usable product with what's feasible given the available technical resources as well as other constraints that are also in play.

It is rare, in my experience, that a Product Manager is faced with all these choices in the span of a single week. This was one of those rare weeks for me.

What drove these decisions

We are closing in on the end of the calendar year and that is affecting each department differently:

• Can we close these deals before the quarter ends? Our Sales team is a rush, scrambling more than normal to close their deals. Sales leadership is pushing everyone to go a little faster and be more aggressive with their prospects.
• What can I tell my customers who have "urgent" questions about next year's product developments? Our Professional Services and Support teams are trying to work with existing customers who can't seem to wait for the future product enhancements that might be just around the corner.
• How will we grow the Product and Tech teams to meet the demands of the business? Our senior management team is trying to lock down schedules and budgets in the planning for next year, hoping to align individual departmental recruiting and hiring plans.
• Did we get as far as we wanted? And of course, my own Product team is doing some reflecting on our efforts over the past year as we think about changes we want to make in the coming year.

As I said before, this is a unique time of the year where Product Management, like other departments, is feeling an increase in pressure to respond to our customers, our fellow employees, and our stakeholders. But I felt more impact during this particular week as I fielded product-related solicitations from every corner of our business. 

The decision: Use each and every opportunity to demonstrate solid product governance.

In a recent, rather insightful exchange with a PM peer, I was made even more aware of how broadly the Product team's decisions will radiate outward to the rest of the organization. For example, the product priorities can influence deals in the Sales pipeline, ideally in a positive way, as we build trust with prospects around the upcoming roadmap commitments.

The choices we make will also impact how the Professional Services team and the customers do or don't utilize our products to solve their problems. In too many situations, I have seen product/platform deficiencies spark some creative workarounds, many of which create even bigger complications for me as I inevitably roll out future product enhancements to address the feature gaps.

I was made even more aware of how broadly the Product team's decisions will radiate outward to the rest of the organization.

Our decisions can also lead to new technical debt (knowingly or unknowingly), that will someday impact downstream engineering work.

Like every Product Manager, I carefully weigh the impact of my decisions with exactly these outcomes in mind.

Plan of attack

While I was still intent on pushing forward with my own Product agenda, I tried to be conscious of the respective priorities and stresses of each department with whom I came in contact. In each circumstance, I looked for a way to balance the needs of all parties while still doing what I thought was best for the long-term health of our business.

Along the way, I also found opportunities to revisit and improve my own methods.

Give a product, take a product

This week, I passed over the ownership of a new product to a very capable PM and was thrilled to see him deftly receive the hand off. It was a big relief for me to be able to move the effort safely off my plate, but it was even more satisfying to watch an experienced Product Manager run the entire exercise without any oversight. I am confident that this decision will help the company deliver the new product to customers according to the original plan.

During the same week, I pulled a separate product initiative away from a different PM on my team, partly because I needed him to focus on (and finish) a separate project. But I was also concerned that the initiative was not advancing at a good pace, which was going to negatively impact a large percentage of our customer base. This was the harder of the two product ownership decisions, but the needs of the customer ultimately prevailed.

Saying no and saying yes to customers

This week, Sales pulled me into two high-profile customer conversations where strategic outcomes were partially dependent on release dates outlined in my product roadmap. In the first case, I knew our teams were ahead of schedule which prompted me to confidently confirm to the customer, "yes, we will absolutely hit those dates for you."

The second conversation didn't go as well. I began the discussion by asking questions meant to help me discover exactly what this organization thought they needed. It didn't take long for me to recognize their request though, as it frequently shows up in competitive sales situations as an obvious land mine strategically placed by another prominent vendor.

My attempt to point out to the customer that they had been misled was not well received. They persisted by parroting their "needs" to us and pinned me down by asking if I had plans to deliver features to address their problem. I said, "No, we do not currently have such a feature and I have no plan to deliver that in the next year.  Specifically, it is not on the product roadmap."

After that call ended, I found myself in some heated discussions with our Sales team who was not altogether pleased that I had been so blunt with the customer. I reflected on this for some time and later came back to apologize and to say that I would try to soften my answers on future such calls. Indeed, I would need to learn better ways of saying "No."

Push and Pull Priorities

This week, I also sat with the CTO to have several talks about our product plans for next year. We agreed that the teams would need to spend more time on product deficit in the months ahead but recognized that it would impact our ability to keep up the pace of innovation in terms of customer-facing features.

Flickr image source: http://tinyurl.com/qhw8hzf

In a simple whiteboard exercise, we were able to list more than 20 separate initiatives that needed prioritization and ultimately reorganized a number of the items on the product roadmap.   

Some of the short-term, scale-related items would ultimately pay off for all of our customers even if they couldn't be demoed in a webinar or training course. Many of these projects were overdue as parts of the underlying platform were in need of repair or rebuilding to handle the next wave of new users. 

I can appreciate the need for ongoing investment in the plumbing, in the supporting architecture and all the frameworks on which our products are built. I understand how the resulting performance of the applications contributes to a positive user experience. Still, it can be hard to sell that to the other stakeholders in the company who can't readily appreciate the improvements. Part of my job in the coming months would be to help extol the virtues of those investments to impatient parties who crave more visible features.  

The impact

I left out many of the other events of the week that included making some necessary personnel changes, planning for an upcoming office space shuffle, and recovering from the annual holiday party. But the net impact of the decisions I described above were ultimately positive for the company. I am confident that we will end the year strong and will have an even better, more productive product year ahead.

Look for more reports from theProductPath around capacity planning, managing stakeholders, and PM credibility here on PM Decisions.

More articles from our blog PM Decisions

Practice humility in product pursuits

Flickr image source: http://tinyurl.com/od9nlno

In recognizing that the string of recent product successes had (perhaps!) inflated my ego and that that might likely affect my judgment, I decided to devote some time to more sobering aspects of being a Product Manager.

It is easy to get swept up in your team's triumphs, to celebrate (even minor) victories, and to take excessive pleasure in the praise others shower on you when times are good. I am as guilty as anyone of basking in the glow of success. Hitting your goals is satisfying indeed and it is tempting to linger there awhile in that satisfaction.

But it can affect your judgment if you get too caught up in your own hype. I was starting to feel like that was happening to me and I wanted to course correct before I began making poor product decisions. Surely there were some facets of my job or details of the product that were not going so well. I wanted to make sure I wasn't ignoring or just glossing over them. One careless misstep could effectively evaporate all the admiration.

What drove this decision

Credibility is crucial in this role. Product Managers must find a way make forward progress with little to no authority and to do that effectively, we must establish ourselves as capable decision makers. The challenge, of course, is that it takes much longer to build credibility than it does to lose it.

I have found that it is often a long march to establish good standing for yourself in the organization. But you can't get there - or hope to stay there long - if you misrepresent yourself by glossing over the many mistakes you make along the way. You have to acknowledge failures to your stakeholders, to your teams and to yourself.

I did not want to lose any of the forward progress I had made and that meant coming down out of the clouds and remind myself that I was still fallible.

The decision: Balance out all the congratulatory feedback and even my own eternal optimism by purposefully exploring activities that would knock me down a notch.

It seemed to me that a good way to knock myself down from the pedestal would be to engage in the kind of activities where there was no actual way to win. I would, therefore, seek out situations that would test my confidence but where the outcomes were not likely to be favorable for me.

Plan of attack

I found good opportunities to help me reset my ego. During this particular week, I tried out some new ideas that would serve up some humility. I think part of what made these exercises effective for me was that they were somewhat disconnected from my role in the organization. I did intentionally seek out product-related activities, but I would not be taking advantage of my job title to affect the respective outcomes.

Taking a turn at being the interviewee

I volunteered to help a colleague who was running a set of user tests for a mobile application. Specifically, he wanted to interview me as a target user of the app. His product initiative was unrelated to my company which meant less personal risk for me. In fact, I convinced myself that, should there be any missteps, my blunders would only be exposed to one other person.

And boy did I have some blunders! Well, technically, it is hard to say that you can get anything wrong in a usability test. As my colleague reminded me, "we are testing the app, not you." I have used that exact phrase in trying to set proper expectations when leading my own experiments, but it is hard to shake the feeling that, as an interviewee, you're not performing adequately.

At one point in the exercise, I thought I had successfully completed the task although it took me longer than I thought it should have. Must be the app I thought. Then, when I was politely informed that I actually had NOT accomplished the task, I was truly embarrassed.

when I was politely informed that I actually had NOT accomplished the task, I was truly embarrassed.

Being on the other side of the table helped me better understand the anxiety that comes with being interviewed. In the long run, this experience will undoubtedly make me a better interviewer, but I will admit that it had the sobering effect that I was looking for.

Reeling from a wave of negative customer feedback

In this same week, I had started to receive some strong reactions from our customers about a recent feature overhaul and none of it was positive. I can't think of anything much more humbling to a Product Manager than hearing that you may have got it wrong: "Can we just go back to the way it was before?"

The feedback was being collected by and funneled through our internal Customer Success team and we took it very seriously. Of course, my instinct, shared by the entire Product team, was to talk directly to the customer. We had, in fact, been doing that throughout the entire product cycle and had already incorporated earlier feedback into the feature through incremental releases.

"Can we just go back to the way it was before?"

Immediately, we went back to review our notes from these previous conversations which included several sessions with one of the customers who was now griping the loudest. I will admit that it is difficult to keep a cool head when intense emotions are involved.

I found this to be the perfect opportunity to revisit my convictions as a Product Manager, to reflect on how much better I still needed to be, and to remind myself how this particular job really never gets easier.

Proceed over a panel in a roomful of peers

And just to pile on even more, I also volunteered to participate as a moderator in a panel discussion for a group of Product Managers from the local community. I had never been a panel moderator and had never worked with this organization or its members. 

Eleanor Roosevelt is credited with saying "Do one thing every day that scares you." Well if you are short on ideas, let me suggest trying your hand at moderating a panel of experts, most of whom are far more experienced than you, and guiding the conversation for a roomful of practitioners in your field.

The impact

Flickr image source: http://tinyurl.com/ph3qp6j

I certainly felt the impact from each of the activities. Any one of them might have been sufficient but combining them all in a single week certainly helped me achieve my goal. And even if you're not working toward the exact same objectives, I can still recommend following some of these pursuits:

• Literally put yourself in your buyer's/user's shoes to help you better develop empathy
• Prepare yourself and your teams for confronting product mistakes so you will know how to move forward
• Do something that scares you, especially around your peers

Look for more reports from theProductPath around product culture, credibility, and the PM role here on PM Decisions.

More articles from our blog PM Decisions

Restore product credibility over time

In taking over as the Head of Products in an organization that had lost a great deal of its momentum, I determined that I desperately needed to rebuild trust in the product development function that is so crucial to the productivity of the teams and to the success of the business.

This particular product story would transpire over many months. The imperfect situation I inherited was not created overnight, nor would it be restored as quickly. Our company had been struggling to consistently deliver products to the market and more importantly, with achieving any real return on our ongoing product investments.

Existing customers had practically given up on expanding their use of our platform and internally, the teams had essentially resigned themselves to promoting, selling, and supporting a clunky and outdated offering.

Something had to be done to restore faith in the product itself and in the collective capabilities of the company.   

What drove this decision

It would not be fair to pin all the troubles on my predecessor or any one team in particular. I still believe that many of our difficulties have stemmed from a real lack of focus - not uncommon for early stage companies. Years of straying from one attractive market to another, chasing irresistible deals, and trying to please too many audiences at the same time had accumulated for us a great pile of problems.

Something had to be done to restore faith in the product itself and in the collective capabilities of the company. 

In somewhat desperate times like these, a company will often bring in new leadership. And in most cases, the troops respond positively and are optimistic, for a time, about the potential for improvement. In my experience, there is usually a brief window where that new person has to prove himself or herself; however, as the collective expectations about fixing what's broken are never realistic - at least in terms of timeframes, this can be a daunting challenge.

This is the environment I walked into 9 months ago. And it would take me at least that long to establish my own credibility and turn the tide for our products. I felt up for the challenge and would build on my previous accomplishments and the solid relationships I had already established throughout the company.

I was determined to make the company proud of our products again by making sure our customers were delighted to use them.

The decision: Consistently make good on authentic product promises by delivering more regularly and more reliably.

A large part of our problems stemmed from chasing product enhancements that did not come from the market but instead from individual customers or worse, from undecided prospects. This lead to all sorts of issues, not the least of which is that we ended up supporting a portfolio of misaligned or disjoint products. I had to stop that practice immediately.

We created another, even more obvious mess by committing to fully-finished features and optimizing our process around uncertain release schedules instead of establishing a delivery cadence that let us incrementally ship software more predictably. Years of bad practices had led to release dates that were constantly slipping which destroyed morale inside the company and frustrated our customers.

Authenticity is important to me as a Product Manager. Ultimately, I would have to prove to all the teams that we were addressing genuine customer pains. The (long) road back to credibility would be built by identifying real market-fit problems and doing the less-flashy work to deliver incremental solutions more consistently over time. 

Plan of attack

So how does a new Product Manager turn things around in a situation like this? How do you get folks to believe in you and be willing to follow, if not fight alongside you? I know I didn't have a quick fix - and I don't think there is one. These kinds of problems aren't created overnight and it is foolish to think that they can be rectified quickly. I will describe the path I have been on for the past 9 months with the hope that it may also help deliver positive results for others.

Learn the product - thoroughly

We have a 10-year-old software platform with hundreds of features and thousands of ways to combine them to solve problems. Unfortunately, there is no accelerated way to ramp up on the entire product suite and no shortcuts to figuring out all of the nuances that have accumulated there over the years. And even after you pick up the core functionality, there is still so much more to learn about why it works the way it does which, of course, affects your ability to go back and tinker with it.

First understand the product, then create a restoration plan. 

I was fortunate to have spent many months embedded with the Sales team, building and delivering product demonstrations to customers and partners and, combined with a natural predilection for tinkering, had become quite familiar with all of the ins and outs of our products. I could now hold my own with the Engineers which I found to be necessary when discussing the feasibility of future enhancements.

It also meant that I could understand and better empathize with all the folks who were struggling with implementations both inside and outside the company.

Build a modest plan and immediately begin delivering on it

The Product team had certainly rolled out roadmaps before I got here. Often, these plans were overly ambitious, had lacked any real cohesion, and could not be easily tied to familiar customer use cases. As the Plans' release dates inevitably slipped again and again, the company's collective confidence drained in both the roadmap and in the products themselves.

So I started somewhat fresh with a new roadmap approach. I borrowed specific roadmapping techniques that other Product people had found to be useful, but my true test would be being able to hit our new Product milestones.

In communicating the new roadmap to the troops, I emphasized that we would be backing down from the unrealistic goals that crippled the previous plans. I wasn't going to promise flashy or bodacious features (at least not anytime soon) that we all knew we could not deliver. I didn't try to dazzle folks with elaborate charts. But most importantly, I didn't explicitly ask up front for people to put their faith in me.

In fact, the early commitments on the new roadmap were the same ones we had already made, just with more realistic dates. We would finish the features already in progress IF and only if they could be tied back to legitimate customer pain points. I joined forces with the Head of Engineering who was also pushing for a more frequent and predictable release schedule and the updated roadmap clearly put us on the path to get there with smaller, more incremental product releases.

As we completed the first few milestones on the plan, I made sure to communicate our moderate and steady progress to everyone. And it was important that we celebrated these early wins as an entire company in events like the monthly Release Preview.

Make the unpopular short-term decisions that are hindering overall progress

As I have discussed before (see here, here, here, ...), there were a number of ongoing product-related problems that needed immediate attention. In some cases, I would be winding down, canceling, archiving, deprioritizing, or flat out reversing previous decisions. But in every case, I made sure I had a solid rationale for doing so and tried to stick to my convictions - any wavering would have undermined the entire effort.

Most of these decisions would be unpopular with at least one person or group in the company. To offset this, I sought to secure support from at least one camp as I went about making these tough calls. Every department had their own list of grievances when it came to the product direction. In making my weekly rounds with each of the groups, I was able to identify specific problems that were causing friction and made small improvements at each turn. Gradually, we put things back on track and were able to focus on the bigger problems as a more unified team. 

Listen to others while I follow my own instincts

It has been my experience that everyone likes for their voice to be heard. So I attempted to speak with as many people as I could throughout the company. I listened to their many suggestions about how we could improve our products. I listened to the reasons they gave for where and why things had gotten off track. And I got more than one earful about what I needed to do to turn things around.

In the end, I incorporated what I could and filed away the rest. It was going to take me many weeks and months to prove myself to the company and over that period, I would have sufficient opportunities to directly address their individual concerns.

The impact

Flickr image source: http://tinyurl.com/phwyc4e

It's now been almost ten months and I can see things starting to turn around at the company. We have hit record sales numbers and our customers have been steadily raving about our products. The teams are now working well together to deliver positive outcomes for our users and for our stakeholders. The Product team has linked up with key allies in Engineering, UX, QA, Operations and Customer Success to restore confidence in our offerings.

Any immediate criticism I had received for some of those unpopular decisions has now been forgotten for the most part, overshadowed by the Product team's more favorable track record. It takes time to address these kinds of problems and to reverse an existing trajectory. Our approval ratings are as high as they have ever been though it was a slow, purposeful march to get to this point.

Look for more reports from theProductPath around the PM Role, managing stakeholders, and PM credibility here on PM Decisions.

More articles from our blog PM Decisions

Guide and advise fellow Product Managers

Flickr image source: http://tinyurl.com/plxquqy

After many rounds of discouraging conversations with less experienced and struggling Product Managers both inside and outside my own company, I decided to assemble and share some helpful resources for advancing one's own PM career.

I believe that we are still in the early development stages of the Software Product Manager (SPM) role and also, that there is a general lack of clarity around this particular breed of Product Manager. That would certainly explain the flood of books, articles and similar resources all aimed at helping PMs understand and navigate this career path. But along with those are an even greater number of online conversations that seem to add to the confusion by attempting to explain it.

Here are a few of the top links returned when searching for "What is a Product Manager":

• What, exactly, is a Product Manager?
• Product Manager 101: What Does A Product Manager Actually Do?
• A Product Manager's Job
• Product Managers: Who are these 'mini-CEOs' and what do they do?

For someone who has recently landed their very first Product gig or is just looking to transition into becoming a Product Manager, this visible and honest industry conversation is simply an indicator of how confusing it can be to get started. And while there are some terrific resources being developed, most new PMs don't even know where to begin. 

What drove this decision

Closer to home, I knew of three individuals at different stages in their own PM careers who were each struggling with the similar problem.

Arthur was already pursuing a UX calling and was a semester away from earning an advanced degree in that area but had spent enough time around Product people to become intrigued with the role and was now curious about whether he could do both.

Brandon had been tapped by his current company 2 years ago to take on a Product Management role after proving himself as a reliable project manager and was now convinced that he wanted to find his next Product opportunity to continue down this path.

Carl had been a Product Manager for several years but had received no formal training and while he had mastered the more tactical activities of getting customer requirements through Engineering to deliver features to customers, he didn't know where to start to improve beyond that.

I found myself in impromptu mentoring conversations with all three in the span of a single week. I took that as a good sign to revisit my own collection of PM material and pull together suitable resources for at least these three practitioners.

The decision: Create simple orientation assignments for Product Managers who have a genuine appetite for advancing their careers. 

The challenge was not finding relevant material but rather curating the collection to zero in on the items that would have the biggest impact. I was looking for artifacts that would be easy to consume, that would provide good direction in the short term, and that might inspire them to explore topics even further on their own.  

Plan of attack

These three colleagues were in different stages of their careers but I knew that all of them would benefit from some strong, foundational material. There is a growing body of informational resources for the SPM but I didn't have a place to point them to get started.

So I published my own list.

Required Reading (AND LISTENING)

Inspired: How to Create Products Customers Love by Marty Cagan

The first question I always ask Product Managers who are just getting started is whether they've found and read Marty Cagan's book, Inspired - How to Create Products Customer Love. I have received nothing but rave reviews from every person to whom I've recommended this book.

I consider it required reading -- and re-reading. It is easy to consume and is filled with great advice for PMs at all stages. But perhaps the greatest benefit for an early-stage Product Manager is that Cagan clearly outlines the role itself and distinguishes it from the related but often overlapping functions of Project Manager, Product Marketer and UX Designer.

And If you need a break from reading, I can't recommend enough the amazing podcast, This is Product Management, created and hosted by Mike Fishbein. Each episode provides a fresh and unique perspective on this incredible role. Mike recruits inspiring guests who generously share their experiences working in and around the Product function. 

Your New PM Job

Gopal Shenoy provides a Getting Started guide for PMs

I then turned our attention to what Product Managers should be thinking about in their early days on the job. Some years back, I came across this wonderful article written by Gopal Shenoy called Software product manager’s first 30 days at a new job …. In it, he lays out a great guide for what good PMs do (or should be doing) in their first few weeks. The list is extensive and a little intimidating - perfect for setting a new PM's expectations.

I encouraged Arthur and Brandon to digest Shenoy's 30-day list and create a distilled version for their own use. And if they made it through that, I further suggested that they read his companion article on what to do in the next 45-90 days.

Brandon is actively interviewing but had not yet found some of the great resources that the PM community has contributed for job hunters. I encouraged him to take a look at one particularly interesting app at http://www.thepminterview.com. The author leverages material from Cracking the PM Interview and Decode and Conquer to create an online, interactive exercise where you can practice your answers to sample interview questions.

Formal Training Programs and Peer Groups

I pointed Carl, who was already embedded on a Product team, to look into cursory workshops and/or full, multi-week courses created specifically for Product Managers. There has been an increase in the number of online or self-guided options from companies like Udemy, but I encouraged Carl to look at local options such as General Assembly's 10-week course or the Pragmatic Marketing program. I explained to him that he would enjoy the added benefit of meeting and networking with peers in his own community.

And speaking of networking, I am a big fan of getting plugged into monthly meet-ups and similar informal, after-work forums related to your career choice. Every month, more and more opportunities spring up for Product Managers to meet and share ideas. I told Arthur, Brandon, and Carl to sign up for an upcoming event in our city and even offered to accompany them.

On the Job Training

Fall in love with a product framework

I prefer to give tactical advice when I can. So I followed up on my previous recommendations (read this book, take this class, join this meet-up, etc.) with a single proposal that I would expect each of them to incorporate differently on their own product paths: fall in love with a product framework.

Over the years, the greater Product community has created and shared many formal templates, authoritative checklists, proven models and reusable processes. A few of these attempt to address the entire product lifecycle but I believe that would be exhausting for an up-and-coming PM to consume, much less apply in practice. Instead, I advocate that new Product Managers zero in on a more discrete area, by starting with what interests them the most.

I used this approach when I was first getting my bearings. I was overwhelmed by all the material and product experts I encountered and was struggling to find any method that I could confidently apply. I eventually discovered Marty Cagan's Opportunity Assessment and used this as a foundation for my building my own method.

And I wouldn't discount the searching process itself. You will inevitably stumble onto new ideas just by sifting through the still disperse product knowledge base to find frameworks that interest you.

Volunteer to do a PM's Job

And what do you do with this new framework you've recently embraced?

I was once told that the best way to get into Product Management is to start doing it. This guru urged would-be PMs to hunt down the closest Product team (or whomever is performing that function) and offer to assist. As someone running a Product team, I genuinely like that approach. But I would argue that showing up empty handed is not as attractive as arriving with expertise around some useful tool that the Product team can use to improve discovery, planning, or execution.

The impact

Ultimately, it is up to Arthur, Brandon, and Carl to move forward at their own pace. I'd like to think my advice is helping them to navigate but I feel like we're still far away from having any kind of proven curriculum. Despite that, I'm seeing more and more people gravitate to this kind of role - and I'm encouraging it. The Product community is fortunate to have professionals from so many disciplines join our ranks, making us a much stronger collective.

Look for more reports from theProductPath around Product teams, PM credibility, and the PM role here on PM Decisions.

More articles from our blog PM Decisions

Fire up the Sales team

Image source: https://www.flickr.com/photos/spacelion/3008520385

After being invited to participate in our mid-year, internal Sales team rally, I decided to deliver a rousing product presentation to get the troops pumped up.

Over the course of my career, I have spent months embedded with various Sales teams and I would recommend it for any aspiring Product Manager looking to better understand their stakeholders. Some of their customs, however, may still be a bit peculiar, at least to me. In particular, there is this practice of routinely gathering the entire Sales team for an entire day or two, typically somewhere away from the office with the intent of re-energizing everyone.

I know that the Sales team, like most other teams, have their own set of priorities and that they don't often stay as connected to the products as I would prefer. So I find it valuable to take advantage of occasions like this to better "align" myself and our products with the Sales team.

What drove this decision

We had recently hired some new folks into the Sales ranks over the past few months and the entire team had been focused on rolling out an updated sales process with our revamped Marketing team. This meant less bandwidth for absorbing the last few rounds of product updates.

Everyone in the company is invited to attend our monthly Release Previews of course but Sales attendance, in particular had been somewhat spotty for awhile.

Now, with this mostly captive audience, I had a chance to focus everyone's attention on our Products and to remind the team how much progress we have made in the last six months.

The decision: Weave together a powerful before/after story that relates the numerous product enhancements as well as our impressive rate of innovation to stir the team and inspire them to carry that message to our customers.

I can't blame our Sales reps for settling into a comfortable routine and sticking with a story that works for them. Asking them to change up their narrative every time we release new software is a little unrealistic. But I knew that the product improvements we had made over the past six months had been significant and would have a big positive impact on the way we all were engaging with our customers.

Our company had indeed devoted a great deal of time to understanding our customers' pain and I knew we could speak to that confidently. But I had sat in on enough product demos to know that there were plenty of rough spots - areas of the product that didn't show particularly well. Much of the Product effort in the first half of the year went to address these specific issues and our story needed to be refreshed to incorporate every one of those Product improvements.  

Plan of attack

They gave me 60 minutes to dazzle the troops.

They gave me 60 minutes to dazzle the troops. Even the best slides would not likely keep their collective attention for that long so I supplemented a PowerPoint presentation with live product demos and tantalizing prototypes to help keep them captivated.

The goal for me was to have everyone walk away with renewed pride in our company's product and more importantly, for each of them to feel even more confident that we were truly the best option for solving our customers' problems.

Create a backdrop for the main narrative

The first step was to set up a familiar context around which I could piece together the different elements of the story. As a framework for my slides, I decided to use a 1-page diagram I had created months earlier as a sales aid to help orient our prospects and drive productive sales discussions. I began by highlighting a number of improvements I had made in this iteration of the diagram to help me grab the team's attention at the very start.

My (abbreviated) presentation flow for the Sales team tells a before/after story using the familiar customer process as the backdrop

Show old screenshots highlighting the known bad spots

The next step was easy. I found old screenshots from the recent past and positioned them on top of the diagram. This had the intended effect of reminding everyone how hard it once was to brag about our solution. During the presentation, I intentionally exaggerated the struggles associated with this familiar but outdated description of our product - but concluded that this awesome team was still able to sell that version. The good news is that it wouldn't get any worse!

Replace with new screenshots

Then, one by one, I swapped in the new hotness. Gradually, I unfolded our updated story to the group showing how all our pain points had been (or would soon be) addressed. Even better, the Product team had introduced entirely new features that helped to strengthen our overall story. The resulting picture not only improved on the known problems but gave the Sales team even more talking points and would help them address customer issues that we might have dodged in the past.

Tease with early prototypes

But wait - there's more! Stacking up all the existing enhancements on a single slide was certainly effective but to really energize the crowd, I then switched gears and started demoing some of the new stuff that was just around the corner.

Using live code that was still working its way through QA along with fancy, clickable prototypes created by our UX team, I began to weave an even stronger narrative for our Sales team to use immediately with their prospects and customers.

The impact

My talk had the intended effect and I was certainly encouraged by all the positive feedback from the team. I do realize that the real payoff for the company will only come when they carry this updated story to the front lines. 

I remember days in recent past where Sales Engineers would brush past certain areas of the product or skip them entirely hoping that the prospect wouldn't notice. I also remember the collective cringe when a savvy customer would ask to explore the next level of detail behind a particularly well-manicured product demonstration.

With this presentation, I made it clear that we would no longer have to avoid those areas of our product. Instead, I urged our team to intentionally stop and even linger at certain points in the demo to prompt more productive conversations. I wanted our customers to ask those tough questions and engage further with us. We had even more reasons to be proud of our company's products and what's more, could now point to an impressive rate of product improvement over the past six months.

Look for more reports from theProductPath around product review, product culture, and socializing product roadmaps here on PM Decisions.

More articles from our blog PM Decisions

Triage an almost bungled feature upgrade

Flickr image source: http://tinyurl.com/pp7daju

In recognizing that our pre-deployment testing had raised unexpected alarms with some customers and our own Support staff, I decided to straighten out the mess by creating a better feature migration path.

We were winding down the days to our next major product release and I thought the planning had been going well. There are always a number of moving parts in a big deployment and it takes no small bit of coordination across teams to pull off a trouble-free rollout.

One of the big announcements this time around was how we had overhauled one of our more prominent features to make it easier to use. And while we had usage data that showed it wasn't exactly mission critical for our existing customers, we still wanted to ensure a smooth migration.

What drove this decision

The upgrade approach we had planned was simply swapping in the new feature in the place of the old one. Any account that was actively using the old feature would continue to work for the 30 days following the release but after that time, all accounts would be have been automatically switched over.

This seemed straightforward enough and indeed, our internal testing and QA efforts proved that this was a clean transition. Where we went wrong however, was not effectively communicating the plan, especially to our internal stakeholders.

The most obvious blunder was in the Release Notes (I wrote) that we circulate internally, weeks before the go-live date. I had made a copy/paste error using some outdated text and reported the exact opposite intent around this migration! As you might imagine, the Customer Success team freaked out when the old feature "suddenly just disappeared".

All fingers were rightfully pointing back to me and my Product Team. What I thought had been weeks of good planning and internal discussion were negated by what was now a small crisis. I needed a good plan to set things straight.

The decision: Instead of forcing a more immediate upgrade on our users, I would stretch out the feature deprecation period and give customers more time and more autonomy to make the transition.

It is worth clarifying that nothing was indeed broken in any customer account and nothing would break as a result of pushing the new feature in the upcoming release. Actually, I could have tried to smooth over the current unrest and push forward as we had originally planned. After all, no actual customer had experienced any problems in their accounts.

But in this case I chose a more cautious path. Even though it would be more work for our tech teams - actually, it would be re-work since we had already removed the old feature and now had to quickly retest the reverted code - I knew the extra effort to create an extended upgrade period would cost us a lot less than having to soothe any confused or disgruntled customers.

Plan of attack

Patience is a virtue - especially in times of crisis. When the voices are beginning to elevate, when email threads are growing exponentially in a matter of hours, and when emergency meetings are being scheduled first thing in the morning, it helps to be able to keep a calm head.

I would have to calibrate our response based on the actual size of the problem.

One of the things I wanted to make sure was that, in attempting to address the problem, we didn't make things any worse than they were already perceived to be. The key to that, in my opinion, was to properly scope the effort. In short, I would need to be able to calibrate our response based on the actual size of the problem.

Understand the full impact of the change

When we did assemble the interested parties in a meeting room and reviewed the situation, one of the first questions I asked was whether we knew the number of customers/accounts that would be affected by the deprecated feature. My own Product team had gathered some numbers weeks earlier but I wanted to know if we had been off in our estimates.

Because there wasn't enough certainty, I had the Engineers run a new set of exhaustive queries to get our hands around the total affected population. Early totals were supplemented by more thorough search results but all reports showed that the impact was far less significant than the recent hype would have suggested.

Flickr image source: http://tinyurl.com/ol3x3jr

Call attention to the deprecated feature

With the Engineering team's help, I committed to reinstating the deprecated feature into the product to help affected customers with their inevitable migration. But in doing so, I insisted that we incorporate some blatant visual cues for the end user so they understood that some action was required.

With minimal work, we were able to introduce a glaring design element intended to draw attention to the deprecated feature. This new call to action would be reinforced with other messaging inside the product and externally as well.

Broadcast (better) to internal and external users 

The steps required for a customer to move to the new, improved feature were straightforward and would likely only take a few minutes to complete. However, I have learned the hard way about underestimating users and so, to err on the side of caution, I committed to providing multiple migration artifacts.

I had the Product team scramble to develop new collateral including a 1-page cheat sheet and a short instructional video to help guide customers on the migration process. In both, we explained how the deprecated feature would be disappearing in the subsequent release to be replaced by the improved option available now and we included a recommended course of action to avoid any problems in their account.

The impact

In the post-mortem discussion, all the teams agreed that the new feature is a much better option for our end users - we had just stumbled a bit in our plan to roll it out to our customers. It was a good lesson for me and one that I'm happy to have tackled before the official release where it could really have escalated.

Look for more reports from theProductPath around product releases, product culture, and PM credibility here on PM Decisions.

More articles from our blog PM Decisions

Upgrade the Product...team

Image source: https://www.flickr.com/photos/drewmaughan/8685770869

In recognizing one of our Product Managers had failed to establish credibility with his peers and colleagues, I decided to refactor the Product team

The Product Manager role is a precarious one. What makes it particularly challenging is that to be successful, you must find ways of influencing other teams in the organization without having any direct authority over them. This is most critical of course when working with software developers or engineers who are the ones building your product.

Credibility is everything. In my experience, you must look to establish credibility quickly after joining a team and then continue to reinforce that with every new initiative. While there are many measures you can use to evaluate a Product Manager's performance, without a solid reputation, there is no foundation for success.    

What drove this decision

I had been monitoring my team's progress for several months and was noticing that one of the Product Managers was struggling with their assignments. I had been supporting the PM privately through one-on-one coaching and also more conspicuously with peers and colleagues. I was looking for evidence that this person could turn things around. The PM needed to build rapport with other Product team members and more importantly, with the Engineers that were taking their direction from the PM.

After many weeks, it was very clear to me that the situation was not going to improve, that the Engineers had run out of patience and that this person was damaging the integrity of the Product team itself.

The decision: Remove the ineffective Product Manager and use the new vacancy to update the entire Product operation

Firing an employee is never easy. I don't like the stress it brings although I have learned some effective techniques that can make the whole exercise less painful for both parties. We do not have a large Product Team so losing even one resource would have a significant negative impact on productivity in the short term. In particular, the other PMs would be taking on additional work to keep our product plans moving forward.

In the past when I have had to make these personnel decisions, I have always struggled with immediate risks to the current project(s). There is a voice in my head asking, "How can we afford to lose a team member now?"  But I have found it helpful to stay focused on the long term benefits and how an upgraded team would more than compensate for any short term momentum loss.

Plan of attack

Knowing about an impending personnel change ahead of time gives you an opportunity to better plan for the disruption. I don't know of any textbook method for tackling this but there are a few best practices I can share with others facing this same situation.

Communicate First to Stakeholders

As I mentioned previously, the Product Manager is a very visible role within the organization. Because the PM must make frequent rounds with Sales, Customer Support, Operations, and Marketing to stay up to date and also to communicate ongoing progress, they are often treated as honorary team members.

So the sudden absence of a team member, even an unofficial one can be unsettling for some groups. Removing the Product Manager from a Sales, Marketing or Support team can mean severing an important link to the products themselves. The PM often serves to bridge informational gaps throughout the organization. It was important to me to keep those connections open and productive during the period while we looked for a replacement.

To minimize disruption, I spoke with all the respective team leads prior to letting the PM go and those gestures were well received. I promised that my team and I would do our best to cover for any deficits and was pleased to hear corresponding messages from the other side of the table.

Image source: https://www.flickr.com/photos/funnyglowingsmurf/7625470418

SHORE UP IN-PROGRESS TASKS

There never seems to be a good time for orchestrating a smooth handoff, especially if the exiting party is unaware of the upcoming transition. I wanted to keep the in-motion product initiatives moving forward and that meant digging a little deeper into this PM's stories and tasks than I would normally have to.

And because this particular PM had been struggling over the past few months, I had even more to do to assess the deficiencies of the latest rounds of work. It took a few days to get a good feel for the situation and what I would need to do to redistribute the work during the interim while we were recruiting a replacement PM.

HEad Off Office Gossip

In most offices above a certain size, there is inevitably going to be some water cooler chatter about personnel changes. This is especially true when an employee is asked to leave versus choosing to make that decision on his or her own.

I prefer to handle the former with very little fanfare and save the goodbye lunches for the latter. To keep the whispers and rumors to a minimum, I spoke briefly to each department about the exiting PM and focused the conversation on our plans to bring on and ramp up a new, stronger resource to reinforce our commitment to the company.

The impact

You may have recently come across some prevailing advice that recommends young, fast moving companies fire fast and hire slow (see here and here for example). And while there is room for healthy debate about the idea of taking your time to find the right next employee, there seems to be near universal agreement about getting rid of dead weight as soon as possible.

I knew I had made the right decision but the lack of any real surprise from the rest of the organization made me wonder if I had acted soon enough. Nevertheless, there is general consensus that the company is now better off and we collectively looking forward to a new PM to strengthen the team and help move the product forward.

Look for more reports from theProductPath around PM credibility and managing product teams here on PM Decisions.

More articles from our blog PM Decisions

Campaign for early Product Roadmap support

Image source: https://www.flickr.com/photos/amycgx/3119640267

To increase the chances that the new Product Roadmap (and my first here) would win favor throughout the company, I decided to conduct a campaign to build early support for the Roadmap itself.

As the new guy now leading the Product team, I had my hands full getting up to speed in the first few weeks. My immediate concern was keeping the current Release on track but the greater challenge was creating a new Product Roadmap for the upcoming year and rapidly drumming up support within the company.

What drove this decision

Taking over a Product team at the beginning of a calendar year has some additional pressures as you might expect. Many internal and external parties are looking for clear indications of the overall product direction, the most concrete of which is the Product Roadmap.

Our company likes to kick off the new year with a rousing, all-hands pep rally for the entire company and one of the meeting's big agenda topics is the presentation of the refreshed Product Roadmap. A big reveal from me that early on would be risky as I hadn't built up sufficient credibility by that point. And with just a few weeks into this PM role, I really hadn’t hadn't been able to speak with as many departments as I had hoped. To pull this off, I needed to build a groundswell of support by having the various department weigh in on, or at least preview the Roadmap before I tried to broadcast it to the masses.

Image source: https://www.flickr.com/photos/israel-mfa/14616944000

The decision: Build support for the new Product Roadmap in stages

My ultimate goal was to present my new Product Roadmap to a room full of supporters. To improve my chances, I started a somewhat calculated crusade to win friends and influence people all around the company.

Plan of attack

There is no one, obvious way to plan a campaign like this but the strategy I recommend is to start small and with people whose opinions you value and push them to poke holes in your product strategy before moving to the next group. I have outlined the approach I took which proved successful.

Start with just the Product team

I began the exercise with my own Product team, perhaps the most empathetic of the groups I would encounter. These folks were the most patient and, because their future paths were most closely linked to the Roadmap, the most eager to engage. With this group's help, I was able to get my initial story straight, confirm the overall themes, and plug some minor gaps in the strategy.

run the roadmap past the Sales Engineers

The next audience I sought, though discretely, was with the Sales Engineers. I had worked closely with this team in the past and knew they would be supportive. I trust their general feedback but it was also important for me to vet out some of the key product decisions with someone who interacted more frequently and directly with our prospects and customers.

pitch to the Key Stakeholders

With my confidence growing, I moved on, skipping over the individual departments to gather all the stakeholders in a room. As you might expect, this group of department heads, their bosses and our senior leadership team is composed of a great number of strong personalities. But when invited to sit alongside their peers, even the feistiest individuals will often tamp down their protests, yielding to and general supporting the views of the larger group. I found this to be the case with my Roadmap presentation and used the inferred approval from the group to launch into the home stretch.

present to Individual Departments

With support from the top, I proceeded to set up separate meetings with each major department including Engineering, Operations, QA, and Customer Support. In each meeting, I tried to highlight those parts of the Roadmap that I thought would appeal most to each group. This proved valuable later, in the larger setting when I was able to direct different topics to specific members of the audience, with the effect of making it seem as though they had already endorsed the individual ideas.

Announce to the Entire company

The final stop in the campaign of dreams was pitching the Roadmap to the entire company. At that point of course, through all my previous efforts, I had eliminated the element of surprise. I had effectively planted sympathetic individuals in the crowd who consciously or not, were giving me the nods of support I needed.

And, while there was no thunderous applause at the end of my presentation, I did get relatively high marks for a "new guy". In fact, a number of people approached me afterwards with positive feedback and great suggestions about how to further socialize the Roadmap internally. For example, we decided to start using the many monitors hung on the walls throughout our office to track our Roadmap progress over the coming weeks & months. 

The impact

When I look back, it is obvious to me that this kind of approach to build internal support takes more cycles than one big reveal. Meeting with each team, one at a time and reviewing the Roadmap over and over was certainly more work in the short term but has paid off. I still have to demonstrate that we can achieve what was promised but I should not be spending as many cycles defending the Roadmap itself.

Look for more reports from theProductPath around product roadmaps, promoting product ideas and working with stakeholders here on PM Decisions.  

More articles from our blog PM Decisions