Brainstorm a product solution for customers

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

After collecting far too many stories about how customers had resorted to stitching together different parts of our product to solve the same problem, I decided to regroup with the extended product team to revisit how we might address the actual needs of our users. 

I can measure the age of some of our primary product components in terms of years. This has positive and negative implications. On the plus side, I have a wealth of real-world application to draw upon as generations of users have been recording feedback with us about what is and isn't working (it is not uncommon for us to work with multiple Administrators at the same company due to turnover). All this input gives the team and I a wealth of information to sift through to find patterns of use.

On the other hand, I now also have both a significantly hardened code base that is more difficult to change and a larger user base that would be affected by any serious product revisions.

What drove this decision

I first started seeing the patterns emerge when I was embedded with the Sales Engineering team. Customers were asking for a way to start the same business process from two different points. We had built a tool specifically to accommodate the first case but unfortunately, to address the other starting point, we and ultimately our customers, were forced to reach for an alternative component.

Administrators found that configuring this second approach was harder but what's worse is that the resulting activity provided a completely dissimilar end user experience!

When I spoke with our Professional Services team who often assist new customers with their initial implementation, I confirmed that this was a common scenario and there was indeed pent up demand for a better solution.

The decision: Go back to the drawing (white-) board to review this prominent customer use case and find a more suitable way to solve this for our users. 

I didn't feel like we needed to start with a blank page. After all, our customers had all found a way to make our software work and many of them had taken the exact same approach to get there. What was bothering me was that we hadn't given them an obvious solution path and more importantly, the end user experience was disjoint and reflected poorly on the product. 

By gathering in one place the sharpest minds from each relevant department in our company, I would have an opportunity to apply some good, creative thinking to the problem. But leading a group discussion like this, especially with multi-disciplinary lineup would require some planning and coordination.   

Plan of attack

I had been gathering details around this problem for months, and so I set about reviewing my notes to create some initial hypotheses. I poured through my notebooks, Jira stories, customer interviews, and related research to organize my thoughts.

In the end, I had some solid starting points for the discussion but stopped well short of outlining a final solution for fear of stifling the creative process.

Prep ahead of time to streamline the conversation

I had some presumptions for how I thought (hoped?) the brainstorming conversation would go. The day before, I stayed after work and put some initial thoughts on a big whiteboard. My intent was to use this as a backdrop for the dialogue.

In my experience, I have found that it is much easier to get people talking when they already have something to bounce ideas off of even if the starting material is somewhat inaccurate or incomplete. 

Assemble a good quorum

I was genuinely interested in securing multiple points of view, but I also wanted to cover my bases so that the outcome could be vetted by all interested stakeholders. To that end, I invited participants from Engineering, UX, and Product as well as from Sales and Professional Services.

The latter was crucial for validating and clarifying the customers' challenges. The former ultimately helped me discover a product solution that was feasible and usable.

Have open-ended questions ready

Brainstorming often works better when there is some amount of prompting involved. I had already planned to facilitate but in a larger group, it can take actual prodding to make sure everyone's voice is heard. I prepared questions, some technical and others around usefulness, to provide sufficient opportunities to participate.

Even if I had already known the answers to the questions, I would still have incorporated them as collaboration tactics to get the ideas flowing and to promote a healthy discourse.

Stay on topic

Brainstorm sessions are expected to wander a bit which can actually encourage involvement and inspiration. But I had scheduled a short meeting so I also had to make sure I got what I needed from the group to be able to move forward. The trick was to limit the number and scope of conversation topics.

I started with a clear topic outline and stated what I needed the group to help me achieve. A few times I had to gently steer the discussion to get it back on track or to park issues that would have derailed us or sapped valuable minutes.

The impact

My meeting of the minds was ultimately a success. We confirmed several of the core hypotheses and as a result, I was able to proceed with my product planning. I was also pleased to have several new ideas enter the mix as well. In fact, there was one outcome in particular that I did not anticipate and that ultimately proved to simplify the resulting solution.

The approach I described here is a more formal approach to brainstorming, but it worked well given my constraints. With a bit more preparation up front and some lightweight oversight for the actual discussion, I was able to achieve positive results in a relatively short period of time.

Look for more reports from theProductPath around product strategy and product culture here on PM Decisions.

More articles from our blog PM Decisions

Take time off to recharge

After an exhausting week filled with a product release, an out of town trade show, and more than a dozen meetings with customers, partners and analysts, I decided to disappear into the woods for awhile.

I don't take enough vacation time, probably less than half of what I'm allotted. I love what I do for a living but I also get stressed out every now and then and have had to get better at recognizing my own specific symptoms. It wouldn't take a trained professional to see that this particular week was going to be exhausting for me so I made sure to pad my travel plans with a few extra days of downtime.

What drove this decision

Right on the heels of another major (and successful!) product release, I hopped on a plane to spend a week on the West Coast as part of a larger team our company was sending to a significant industry expo. At the show, I gave a formal talk to announce a new product we had spent months building and validating with customers. The presentation went well and our new product was a hit with the attendees.

With all the right people gathered in one central place, we had also scheduled back-to-back meetings with customers and prospects, partners and integrators, as well as analysts and influencers. I was running almost non-stop from room to room trying to keep up. I do enjoy all the activity, even at the heightened pace but it is not sustainable and by the end of the week, I ran out of steam.

The decision: Leave the office, the job, and all the people behind and soak up some solace in solitude.

My particular form of relaxation is to head off into the woods, by myself on a very long hike. I realize this isn't for everyone - in fact, I haven't found too many people who share my preferences for spending hours or days embedded in nature.

But it really doesn't matter how you unwind and recharge. The trick is to find a way to unplug from the day to day schedule and fill the gaps with a different agenda - one that revitalizes you, stimulates your creativity, and boosts your spirit.

Plan of attack

One of the things I like most about hiking and camping is that is practically forces you off the grid. I always bring a cell phone but I find that I don't mind so much when the battery dies at the end of the 2nd day. If you're used to being connected 100 per cent of the time, then it will likely take longer for you to appreciate that your brain can find other things with which to occupy itself. It is often during these stretches that I get real inspiration.

Backpacking can be especially liberating. When you have to carry on your back everything you would need in order to sleep, cook, eat, drink, clean, clothe, bathe, entertain, and protect yourself for days at a time, you inevitably learn to value the art of keeping it simple. I try to recall that mindset whenever I'm staring down a large problem at work.

MVP = Minimally Visited Path

I am intentionally seeking solitude on trips like this. I want to be far enough away from human contact that I don't even have to bother with casual pleasantries. To achieve this, I have to retreat far from the parking lots, down the more primitive trails, and often near the edges of my own comfort zone. There is nothing that helps me turn my thoughts away from my typical daily routine than navigating unfamiliar back country paths on my own.

I'm no Daniel Boone but I do appreciate a spot deep in the woods where only the faint sound of an occasional overhead airplane interrupts the long stretches of silence. I can sit in a hammock for hours, staring up at the trees, resting my muscles and my brain.

Refer to the map often

I rely on a roadmap to guide my day to day activities as Product Manager. My team and I use the map to guide our activities and to communicate direction with our customers and stakeholders. It is not uncommon for me to carry around a portable version of the product roadmap for important or even impromptu discussions around the office.

When I'm away from all that, say hiking through unknown territory, I find that a good map offers the same comfort. I do occasionally take a wrong turn but I generally try to keep my bearings and have learned not to panic if things don't necessarily go according to plan.

In both cases, the map provides me with support and allows me to be more relaxed in my decision making. 

Log miles, not bugs

On a long, multi-day hike, about the only metric I pay attention to are the miles I've already walked and how much more I have to go. I just completed a 28-mile loop through a giant redwoods park in California and I can tell you the last thing on my mind was a list of software-related bugs. Your rhythm quickly adapts out there. You wake at sunrise and go to sleep when the sun goes down. Away from the short-term urgencies of features and enhancements, requirements and usability, bugs and regression testing, your mind can turn back to the larger product challenges, the real customer needs, and the decisions that will make your business successful.

For me, a really long walk is often the perfect opportunity to re-focus my thoughts. 

The impact

While I can't say that I am fully recharged, I did thoroughly enjoy the time away. Aside from receding into a truly awesome natural setting, I was also quite humbled having spent several days alone with gigantic trees that are more than 1,000 years old. I now return to the office surroundings and the familiar duties of my role. I have some new memories to keep me stimulated while I adjust back into business mode. It's time to plug in my phone, catch up on email and start working through all these new ideas. 

Look for more reports from theProductPath here on PM Decisions.

More articles from our blog PM Decisions

Speak on products in a public forum

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

As part of an effort to continuously hone my communication skills - an ability that is vital for all aspiring and incumbent Product Managers, I decided to seek out opportunities to deliver product messages to the outside world.

It took me many years to realize that a day full of nothing but constructive discussions across the various business units could indeed be considered a productive day.

It's not like I don't get the chance to talk about products or product development every day - on good days, that's all I do. To be an effective PM, you must develop methods of interacting with a diverse set of internal and external "customers" and to really succeed, you simply MUST be a solid communicator. This job is all about communication, with almost every part of the business (sorry Legal teams). We Product people are full-time arbitrators, back room mediators, and business-to-tech translators.

In fact, it took me many years to realize that a day full of nothing but constructive discussions across the various business units could indeed be considered a productive day.  

What drove this decision

I can't remember seeing a resume that didn't highlight "excellent communication skills". I would like to think I'm competent in expressing myself through company emails, in formal presentations to internal stakeholders, in one on one interactions with customers and even with online mediums like this year-in-the-life PM blog.

But the one area that I have a hard time leveling up on is public speaking. I love what I do and it always seems easier to talk about something you're passionate about so I set about finding opportunities to practice in front of a live audience.

The decision: Sign up for several public speaking engagements to resume exercising those stagnating muscles.

I've already stressed the importance of communication but I want to be clear that I don't consider public speaking to be mandatory for this role. However, I will propose that if you're delivering a certain type of presentation in a certain setting, that you will use the same physical and mental muscle groups. Having to convince groups of people that you understand their problems while proposing fresh and unique answers to those problems would be familiar territory and I wanted to find those experiences in a more formal (and formidable) environment.

Plan of attack

As it turned out, I didn't have to look very hard. Not only are there are readily available opportunities as part of the normal course of product development, but you're not likely to find many people competing hard to take on those assignments. In a relatively short period of time, I was able to schedule three very different speaking slots on my PM calendar.

Deliver product release webinar to customers

As a kind of "warmup exercise", I volunteered to deliver the public webinar for our next product release where I could extoll the virtues of the latest round of improvements to our products to a broad audience of customers, prospects, partners, and more. Using a virtual, web-based delivery format meant that I wouldn't be face-to-face with my audience but it was still a public forum where I would need to be poised, polished, and professional.

I was fortunate in this case to have an existing presentation template to use and of course I was intimately familiar with the material since my team had just spent the last few weeks working through the backlog. The content and accompanying script was new of course and I also wove in a few live product demos to increase the degree of difficulty.

With some rehearsals and an early dry run recording to be shared after the official webinar, I was ready to go. All the preparation paid off and the live event was a success. I had fewer jitters than if I had actually been on stage but I certainly experienced a bit of the same anxiety. 

Announce new product at industry event

The next venue was much more daunting. At a major trade show, I signed up to deliver a formal presentation where I would announce a new product for the company. The talk was promoted by our Marketing team and would likely attract a range of participants from the amiable (e.g. happy customers, supportive co-workers, and curious passers-by) to the slightly more surlier (competitors, disgruntled former employees, and grumpy show floor stalkers looking for free swag).

I would be condensing more than a year's worth of product discovery and delivery into a 20 minute presentation which would be hard enough.

For this talk, there was no template. I knew I would be condensing more than a year's worth of product discovery and delivery into a 20-minute presentation which would be hard enough. But it also had to be much more engaging as I would be competing with all the distractions of the surrounding event.

I sketched out the general flow of the talk, liberally borrowing techniques and best practices from everywhere could. Immediately afterword, I literally grabbed a few of our internal creative types (thanks creative types!) to help me create a beautiful presentation to support my narrative.

We ultimately landed on a simple, but effective style that needed fewer words on the screen and incorporated a bit of audience participation. The noisy venue wasn't necessarily ideal and truthfully the product practically sells itself (thanks Product!) but I'll take a small bit of the credit for what was a captivating, if not compelling presentation.

Lecture about product management to college class

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

My final challenge was to be the most trepidatious. Many of us can identify with the general anxiety of public speaking but when you combine that with that recurring nightmare we all have about finding ourselves back in school completely unprepared for some assignment, you can appreciate my plight.

I had done a similar session as a guest lecture at this same university earlier in the year and was now being invited back to speak to a new class both on the broader topic of Product Management as well as its strong connection to UX. In this instance, I would be able to step away from my day-to-day work with my own company's products and talk about product-related topics about which I am more passionate.

The impact

I'm not exactly sure how to measure the impact of these speaking opportunities but I'll confess that is better to have them behind me. I am satisfied with having pushed myself outside my normal comfort zone and will likely do so again. Most Product Managers I know already have enough stress in their daily routine and would not willingly introduce more. One small tip I can share from this exercise is that compared to public speaking, facing down a rude customer or talking a hot-headed CEO off the ledge or feuding with a belligerent Engineer all seem like walks in the park!

Look for more reports from theProductPath here on PM Decisions.

Showcase roadmap to advance a large deal

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

To accelerate the largest sales opportunity in our pipeline, I agreed to lead a spirited, product-oriented discussion with the prospect free from any heavy sales pressure.

It is not uncommon for Sales to pull the Product team into large deals, especially late in the sales cycle where there is a need for even greater assurance that we are a vendor on which they can rely. I have developed and shared sanitized, customer-facing roadmaps on many occasions and have even delivered custom product demos to help our Reps close their transactions.

I do have to be careful about sharing too much information prematurely. Even hinting that the product may be headed down a particular path can send an overeager Account Executive spiraling off in a wrong direction. But I do appreciate the positive impact for a potential customer to "be invited to a private meeting with the head of our Product group." I also think it is valuable to assist in efforts like these and to maintain a healthy relationship with our revenue-producing Sales team.    

What drove this decision

 I am firmly against letting any one customer hold sway over the roadmap and my product priorities

I was familiar with this particular prospect - indeed we had all been watching the opportunity progress over the past few months. The use case was squarely in our wheelhouse but the prospect had identified a few specific feature requests that we might not otherwise have delivered in a suitable time frame. And while I am firmly against letting any one customer hold sway over the roadmap and my product priorities, I do believe there is room for a large, active user base to weigh in on decisions about product direction. 

The decision: Demonstrate an impressive pace of innovation through a series of past accomplishments and future intentions and encourage the customer to weigh in on the ongoing roadmap priorities.  

Image source: http://tinyurl.com/qjogg57

Customer seem to love talking about roadmaps. Even when you lay out all the disclaimers about lack of certainty and best guess estimates, there is still enough curiosity remaining to drive a lively conversation.

I don't mind sharing our vision for the products and where I'd like to take them in the months and years ahead. There are certain paths that are quite clear to me at the moment and others that are more directional in nature.

I am also very comfortable weaving a strong product story that incorporates past achievements with current work and that extends into the not-to-distant future.   

Plan of attack

As I mentioned, the meeting was not intended to be overly sales-y but the parties on both sides knew this would be another part of our pitch for their business. I built a product-focused agenda that put our offerings in the best possible light. I accentuated the products and features that were high on their list of needs, starting with items for which we had just completed development and moving to the ones that were still several months away.

Demonstrate A working version of an early prototype 

Previously in the same sales process, I shared some clickable prototypes with this prospect to give them an idea of where we were headed. One prototype in particular was more relevant to their primary use case and the prospect had showed great interest at the time.

The Product and Engineering teams had since made good progress with the development of this feature so I used this opportunity to walk the prospect through a fully implemented version. The feature was intended to be the highlight of the upcoming product release so the demonstration was positioned as an early and somewhat exclusive sneak peak.

Preview unreleased features

Another keen area of interest for the prospect happened to overlap with one of my high priority product initiatives. I had been pushing our internal teams to complete the first iteration of a major component whose full delivery schedule would stretch out for many more months.

It turned out that while this initial cut was not quite ready for widespread use, it was certainly viable for use in pilot exercises like the one the prospect had scheduled. Again, we emphasized the exclusive access being offered and made sure to highlight our company's rapid pace of development.    

Share detailed roadmap of prospect's most requested feature

After completing the feature demonstrations (which were well-received), I switched gears and walked through a customized product roadmap. The prospect had expressed a need for functionality that was not yet part of our product but that would represent a natural extension to the platform.

While I was careful not to make promises about specific dates, I was able to talk through a plausible plan that illustrated the incremental delivery of their requested functionality. 

Unveil results of relevant internal research efforts

In a separate internal research & development initiative, I had recruited a data scientist to help us look for useful and insightful ways to share the data we were collecting around our customers' workflows. She had produced some impressive dashboard-style reports and charts that were scoring huge points with our internal stakeholders. 

So, as the big finale to the conversation with our prospect, I rolled out these artifacts and tied them back to the workflows they would ultimately use in their own solutions. The resulting discussion was quite fruitful for both parties as we collectively described a future partnership filled with great potential.

The impact

The short version is that it worked! The conversation was very productive and we impressed the prospect enough to have them throw more weight behind the initiative. Nothing specific was promised but they did acknowledge our commitment to advancing the products and their unique opportunity to work with us to guide its long-term development.

Look for more reports from theProductPath around product reviews, socializing product roadmaps, and the PM role here on PM Decisions.

More articles from our blog PM Decisions

Conduct high-priority product research

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

To address one of the most critical problem areas for customers using our software platform, I decided to roll up my sleeves and conduct the fieldwork myself.

For many months, we had been recording feedback from our customers, some direct, some indirect around one particular area of the product. Everyone agreed that we had delivered really powerful features - the common challenge was in the setup and configuration. We had made it too complex to use this valuable piece of the product! 

I couldn’t agree more. I knew how hard it was, even for more technical users to configure the tools. I have a deep programming background but even I would struggle trying to ramp up on proprietary schemas with cryptic configuration syntax and poor documentation.

We had been attempting to compensate and even head off frustrated customers by offering to have our own Professional Services team help get customers up and running. But that only served to delay the inevitable as the complaints would then change to “even if you build it for me the first time, I’m not confident I can take it over and maintain it!"

What drove this decision

I had been anticipating a suitable window of time where we could focus on revisiting and rethinking these problems. The teams had been making good progress on some of the pre-requisite components that would be leveraged to rebuild this key feature of our platform. It was time to initiate a round of interviews with customers about how they use the current product, what (if anything) they liked about it and what (again, if anything) they could point to that causes problems for them or their end users.

I wanted to take full advantage of this opportunity to get out of the building, to speak directly to users and reinforce this important research activity with the members of my Product team. Mostly though, I wanted to improve our product and make our customers happy.

The decision: Enlist the help of our User Research expert to coordinate formal interviews with a suitable group of administrators and end users from our active customer base.  

I am fortunate to have a talented resource on our team who has raised the bar around user research for our entire company. She continues to guide us all on the finer points of interviewing users early on around product discovery and later on for product usefulness and usability. With her by my side, I felt very confident that we would get to the crux of the problems and ultimately, be able to prioritize the work to come.

While I was eager to get started and optimistic about what we would learn, I heeded my colleague’s advice and adhered to the plan we made to ensure a favorable outcome.

Plan of attack

It was so tempting to just start writing requirements. But I've been wrong before.

I have used our product internally and I have also demoed it hundreds of times to customers so I felt confident that I knew what was wrong and what would need to be fixed. It was so tempting to just start writing requirements.

But I’ve been wrong before. Let me say that again, I’ve been wrong before. I have felt strongly about how our product should work and went straight to the Engineers with requirements only to find out, after they had spent valuable time implementing the stories that there were no customers lined up to use the new enhancements.

Start with hypotheses and a good prototype

Because I was so familiar with this particular part of our platform, I was able to quickly compose a lengthy list of hypotheses of pain points where I would expect to hear complaints from both heavy and casual users:

• We believe Admins are struggling to initially configure a URL to set up a new instance of [tool] in environments like Salesforce.com.
• We believe end users are frustrated with the number of clicks required to complete the ... process, especially if only one document is necessary.
• We believe Admins are resisting adopting and expanding their use of [tool] because it lacks good error handling, is difficult to test, and has too few options for controlling its behavior for the end user.
• We believe end users struggle with scrolling and otherwise navigating through the different areas of the page, e.g. with long lists of templates or with very long data forms and may find it helpful to track incremental progress as they work through sections of a longer form.
• We believe end users are underwhelmed with the stark layout of the [tool] page, the lack of branding, and the lack of any help text.
• We believe end users struggle with using the [tool] with different browser window sizes, specifically when the buttons move around when the page is resized.
• ... 

I then had the UX team mock up a clickable prototype that addressed some of the primary concerns and that would allow us to better engage with our interviewees.  

Recruit and track participants

To build a list of participants, I first reviewed the customers who were already part of our formal “labs” program (always be recruiting!). Then, I put the word out to our Sales and Professional Services teams to identify other viable customers with whom we could talk. The resulting list was manageable enough for us to track using a shared spreadsheet that included contact information, interview dates, and miscellaneous notes.

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

Contact Names	Organization	Preferred Phone/Email	Participation	Last Contact Date	Future Participation	Primary Internal Contact	Notes
Nellie Bluth	The Bluth Company	nbluth@thebluths.com	Asked to be included in Fall research initiatives	7/12/15	Also willing to help with...	Maggie Lyes, Acct Mgr	Has been helpful in the past but admits to not being technical

Conduct and record the interviews

When we had accumulated a sufficient list of suitable users, I crafted and sent out an email invite along these lines:

“Hello Vincenzo, I would like to enlist your help for a product research initiative.

I head up the Product team and am leading an active project to learn more about how customers are using our tools. I am reaching out to you because your group is currently using [tool]. I believe you would be able to provide some great feedback on what is and isn’t working well.

If you are interested in participating, the next steps are easy:

1 - Reply to this email with some available interview times over the next 2-3 weeks.
For example, “Tuesday mornings are better”, “tomorrow”, “Wed/Thurs between 3-5pm Pacific”.

2 - Prepare to walk us through how you or your end users use [tool] today

This is a great opportunity to tell us about your successes with [tool] as well as things that would make it easier for you. The conversation should not take more than 45 minutes.”

Not surprisingly, our more fervent users responded immediately. With the others, it sometimes took a little more effort to secure the interviews. We mostly used virtual web meetings to conduct and record the interviews where the customer did most of the driving while we watched.

Our agenda for the interviews followed this path:

1. Show us how you use the product today [50% of the interview time was spent here]
2. As an [administrator, end user], what would you say if anything, are your favorite things about [tool]? [10%]
3. What, if anything causes you or your users problems when using [tool]? [20%]
4. Switching gears, we'd like to show you our ideas for a new design... [20%]

I had an intern transcribe notes from the recordings, putting all the material in a central repository so we could index it properly and share it with the rest of Product and Engineering.

The impact

The customer interviews went smoothly giving me exactly what I had hoped to obtain. There was plenty of validation around our current shortcomings, some surprises about certain attributes that users found valuable, and an abundance of constructive griping. The early prototype seemed to be a hit with users and gave me additional confidence to pursue that path.

I expect to deliver a first round of product improvements in the very next release and will continue to engage these customers to validate our efforts.  Look for more reports from theProductPath around customer research, product validation, and feature prioritization here on PM Decisions.

More articles from our blog PM Decisions

Respond to unhappy customers

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

To learn more about post-purchase sentiment, I decided to engage with our Customer Success team and become more aware of where our users were struggling.

I will admit that my Product team and I tend to spend more time interviewing and talking with amicable customers. That is not to say that we only approach our happy users; in fact, a fair number of the research-oriented conversations have been tempestuous. Indeed, through our collective research efforts over the past year, we have collected quite a bit of product feedback that would land well on the other side of "needs improvement".

But in this exercise, I wanted to turn my attention specifically to customers who were in peril. And I wanted to go straight to the front lines.

What drove this decision

In addition to what we were learning from the interviews we had been conducting with customers and prospects around new features and enhancements, I also wanted to know more about our product's pain points. And I thought that a great way to do that was to talk with customers who were currently lodging their complaints with our Support team.

The decision: Carve out time to listen to and understand some of the problems customers were having with our product and to help identify ways to address each distinct concern.

In span of a single week, I was able to participate in three separate support cases. I got a chance to hear, in some cases first-hand, from customers who had legitimate complaints about:

1. An unacceptable implementation scenario
2. An (unintentional) product feature gap
3. A grueling Administrator on-boarding experience

These scenarios afforded me with a good cross-section of problems to explore. One was griping about our product's inability to satisfy their complex security problem. Another had caught a change we had made in a recent release that legitimately "broke" one of their use cases. And a third was trudging through our formal training course and was beginning to grasp all that he would ultimately have to learn to support his own company's solution.

Plan of attack

I was intrigued to have three customers with three very different concerns. My process for each was similar however. I spoke with Customer Success person who was interfacing directly with the users, tried my best to assess the particular situation and made sure I understood each customer's own challenge. 

In the end, I helped to resolve each situation but with three very different outcomes.

Scenario 1 - "Fire" a customer for which there was truly no fit

My first conversation revolved around a newer customer who had been planning to go live with their implementation in the next few weeks. In working through their initial project, however, they had determined that they needed a much more sophisticated security scheme and were now struggling with that part of our platform.

It did not take me long to recognize we were at an impasse.

Somewhere along the way, we had clearly misled this particular customer. We had since exhausted all the obvious and even more creative options and I confirmed that we would not be otherwise enhancing the product to support their unique use case.

It did not take me long to recognize we were at an impasse. Looking to quickly resolve the situation, we made the tough decision to rip up the customer's contract and return their money.

Scenario 2 - Escalate a support ticket regarding a product oversight

My next conversation was much different. Here a long-time customer had submitted a complaint with our Support team about a small feature that was removed in a recent product release. It was clear to me that we screwed up.

It was clear to me that we had screwed up.

After hearing their scenario, I agreed and admitted that we had inadvertently taken away a small piece of functionality that they had been relying on. I recommended that we escalate the Support ticket to trigger a feature enhancement request that would bring back comparable functionality to help restore their solution.

Scenario 3 - Meet face-to-face with an overwrought Administrator

And finally, toward the end of the week, I was made aware of another new customer who had been floundering a bit. The designated "administrator" at this company, who was in charge of making it all work was currently enrolled in our (highly recommended) training class to learn the ins and outs of our software but was laboring under the breadth and depth of the course material.

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

In truth, the original implementation project was poorly scoped and was running over budget. It was clear that more time would be needed to complete the work. But the Administrator was becoming even more unsure about his ability to ultimately support his own company's users when the solution was finally deployed.

I scheduled an hour meeting with him after the training class (we actually talked for more than 90 minutes) and listened to his concerns. After some healthy venting, he ultimately agreed that none of his immediate doubts were tied to the platform itself. Instead we decided to revisit the original statement of work and work with Sales and Professional Services to properly expand the scope of the project to fit his organization's needs.

The impact

Looking back, I am not sure if my products are better off as a result of these interactions. At the end of the week, I had been engaged in three unique customer scenarios and delivered three different resolutions:

1. Defend the product, even if it meant losing revenue and risking our reputation
2. Admit our product mistakes and try to earn back the customer's trust
3. Reset a (new) customer's product expectations and help them find a successful path forward

Look for more reports from theProductPath around customer research, product validation, and voice of the customer here on PM Decisions.

More articles from our blog PM Decisions

Prep teams for upcoming trade show

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

Knowing that our most important industry trade show was barely a month away, I wanted to do my part to make sure we were adequately prepared and that our products were positioned to show well at the event.

Trade shows can be ideal opportunities for Product teams. If your company registers as a vendor, you can take advantage of your booth space and deploy an engaging team to help introduce new products and announce exciting new features to people cruising through the exhibition hall maze.

You may also gather lightweight customer data from the dozens of rapid conversations your booth team will have with passers-by. If you have already nailed your target market and are promoting the right product messages ahead of time, some may actually seek you out as they wander the aisles.

Even when you don’t have a booth and are just registered as an attendee, you can still take advantage of the fact that for a few days at least, a highly concentrated population of your potential customer base will be under one roof. With enough planning, you could still set up meetings with key prospects, industry analysts and partners. You should also carve out some cycles in your schedule to gather information to update your intel on the competition.

I wouldn’t exactly call us trade show veterans but over the years, we had steadily improved our collective efforts. This year, I wanted to raise the bar even higher, especially for my team.  

What drove this decision

This annual industry event precipitated our biggest marketing campaign of the year and we intended to pull out all the stops. We started setting up meeting schedules with customers and prospects weeks in advance and of course, were busy making preparations to lure in new contacts and leads. That meant crisp product demos that hit all the right notes. We needed to highlight the latest improvements to our story in a concise but captivating way to increase our chances of engagement.

Most of our close partners would also be in attendance and the show would provide us with an opportunity to reconnect with them as well, exchanging updates and looking for new integration or implementation options to serve our joint customers.

This was going to take some coordination - none of it was going to just happen magically. 

The decision: Kick off early planning for the show to synchronize all the product-related activities across departments.

We needed to highlight the latest improvements to our story in a concise but captivating way to increase our chances of engagement.

I don’t think it’s wise to pin all your product/sales hopes on a single event but I have seen first hand how a large industry event like this can become a natural rallying point for the Product, Marketing, and Sales teams.

I had already coordinated our next major product release to line up with the event dates so that we would have exciting new announcements to share at the show. That was a good start.

To make sure we would get the most out of the show, I would need to circle back with other departments to work on making all the other pieces fall into place.

Plan of attack

With good preparation, we would likely have hundreds of opportunities to tell and sell our story to a mostly captive audience. I wanted to support our company's collective efforts and put our products directly in the spotlight. That meant having persuasive product demos, queuing up notable product announcements, promoting influential partnerships, and more.

I also had to make sure my own team would be taking full advantage of all the available resources at the show.

Review product demos with the Sales Team

I started by spending some time with our Sales Engineering team to review the product features that I thought should be highlighted to create compelling demos for the traffic we would see in both the booth and in our private meeting rooms.

We rely on Sales Engineers to help execute the technical part of the B2B sales process. Together with the Sales Reps, they will tailor and deliver product demonstrations based on a joint understanding of the customer's needs. At a busy trade show we don't often have the time to fully qualify leads and so we have to tweak our methods.

In recognizing that most attendees would not be able to spend more than a few minutes with us, we optimized the familiar customer story to have even more impact in a shortened discussion. 

Confirm launch plans for a new product

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

Our big theme for this year's show was around the launch of our new mobile application. My partner over in Product Marketing had started orchestrating a full communication plan which would culminate in a product unveiling at the upcoming event. Aside from being able to show off the product itself (see Demos above), I wanted to make sure all our messaging was on target.

We had also been seeking out opportunities to further promote the new product outside of our own booth. For example, we applied for and were awarded a special "innovator" designation in the vendor listings. We also secured a coveted time slot to present at one of the show's more prominent venues where I would have much more time and resources to advertise our newest offering.

Finalize partnership integration announcements

Through discussions with a few of our strategic partners, we had determined that the trade show would also be a great time to create some joint buzz. One integration partner, for example, was going to use the show to significantly step up their own presence and our company had a part to play in that upcoming marketing blitz.

With another partner, we focused on a more tactical story. Rather than each of us independently promoting our own products, we agreed to highlight product integrations and the success our customers had realized by using our respective public APIs. Of course, it always helps to have these customers come forward and attest to our claims.   

Synchronize agendas with the Product team

And finally, I sat down with my own team to review our strategy for consuming as much information as possible during the show. We walked through the complete list of formal sessions, scheduled workshops, and other informal gatherings to build agendas that would provide maximum coverage. It was tempting to completely fill up everyone's calendar but we also wanted to be able to accommodate spontaneous and unplanned events as well.

The impact

At the time of this writing, the trade show is still more than three weeks away. There will likely be many more details to work through before we all hop on airplanes and head out. I feel good about our preparation to date and will continue to push all the teams to band together to deliver a positive outcome for our company.

Look for more reports from theProductPath around managing product teams and getting out of the building here on PM Decisions.

More articles from our blog PM Decisions

Initiate a few modest R&D projects

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

After getting our major roadmap items underway and finding our rhythm with smaller bugs and enhancement requests, I decided it was time to launch a series of background research tasks.

I don’t want to give the impression that we have tons of spare bandwidth. We are struggling with the same resource constraints that plague most Product teams but I believe there is value in prudent technical experimentation. In my experience, even the most ambitious Product Roadmaps are primarily designed to keep everyone going down the same path and they don’t afford much room for concurrent product exploration - and I’m not talking about unexpected wrong turns!

Sometimes you need to launch a few parallel pursuits to introduce new ideas and shake things up.

What drove this decision

I continue to be impressed with our entire technical team and am convinced that there is even more potential there that we can tap into through targeted endeavors. In this case, the team had been making favorable progress on several, in-motion product initiatives and that prompted me to think a little further out than I had been.

Several months back, we had embarked on a plan to upgrade some of the underlying technology in our core platform, partly on the promise that it would deliver advanced functionality above and beyond the legacy components it was replacing. We were now closing in on a major delivery milestone and had a sound plan for the upcoming transition. That inspired confidence and afforded me with some breathing room to further explore the features of this new technology.

Sometimes you need to launch a few parallel pursuits to introduce new ideas and shake things up.

Separately, in another work stream, we had been investing a great deal of resources into building a new data repository to capture information related to the user activity in every automated business process. The initial payoff would be the launch of a new mobile application which gives users unprecedented visibility into their own workflows.

The mobile app was now being rolled out to customers but that initial investment was always intended to yield more for us and for our users. This seemed like a good time to start work on the next phase of that product initiative.

The decision: Recruit uniquely qualified resources to kick off independent, well-scoped initiatives with a high potential to excite both customers and stakeholders.

R&D efforts are not always guaranteed to deliver positive or even actionable results. Still, I didn’t want my first ventures to fall flat as I intended to follow up with additional waves of experimentation. Ideally, the R&D projects would help to determine which ideas were feasibility and for those, what we should expect in terms of level-of-effort to implement, deliver and support them. This would help me assess how and when to fold them into the Product Roadmap.

I was also planning to share the results with the Management Team and our Board in order to show what we might be capable of delivering at the far end of the Roadmap. A secondary goal for me then was to demonstrate early success and improve the chances of funding future R&D work.

Plan of attack

These initial projects were trial balloons for me and the Product team. If we succeeded in producing positive results, we were likely to be encouraged to continue exploring and experimenting. To increase our chances of success, I took care to limit the scope of each effort, to pick the right team resources, and to schedule shorter term deliverables. 

Disclaimer: As R&D projects can be sensitive and can often impact a business' competitive advantage, I have chosen to sanitize and share just 2 of the projects here.

Project A explored the viability of an inverted search feature that enables an end user to determine if a given document matches one or more search terms. Our customers have shared use cases where they need to know if a modified document still contains one or more paragraphs, terms, etc. An inverted search could discern whether a given contract contained one more standard clauses for example.

Project B looked to expand our company’s use of analytics to report on and ultimately improve document workflows. Customers were already investing heavily into our platform’s workflow features to automate their business processes and I wanted to be able to give them much more data to evaluate the people, process, and documents involved in those workflows.

Scope each effort

In my opinion, the most important factor for success was in how we defined the projects. Too broad and we might never see any results. Too small and they may be de-prioritized or even dismissed.

For the first project, I needed to show the general applicability of the inverted search and the relative effort to configure the function. We didn’t need to tackle complicated documents or complex search terms but we did need to stay relevant to our customers’ use cases. The goal for this project was to prove the feasibility of the technology - usability would be addressed in a separate effort.

The other project was quite different. Here I was looking to identify the overlap of actual customer inquiries and available analytic data. The goal of this project was to find as many good matches as possible between what our customer research had surfaced around visibility into workflow processes and the rich analytics we could be generating in the future.

Enlist Internal and External resources

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

To kick off Project A, I cornered one of our Software Architects and bribed him with pastries - a low-cost recruiting tool!  He is the resource who was primarily responsible for introducing the new technology to the Tech team and who had been overseeing its implementation during the past few months. I sat down with him and painted the picture of how we could use the advanced features of this technology to address real customer problems that were going unsolved. He understood the benefits and like me, recognized the large payoff of a relatively minor product investment. I had no trouble convincing him of the value of a proof-of-concept and promised to carve out time for him to explore this during the upcoming sprints.

For Project B, I went outside the company to find subject matter expertise. I had been introduced to a woman who specializes in all things data, metrics, analytics, and visualization. I had seen examples of her previous work where, given very little in terms of schemas or actual data, she produced some amazing and insightful dashboards. This was exactly the kind of impact I was looking to make with our own embryonic data store. After explaining what little I had to start with but where I was hoping to go, she presented a reasonable proposal that fit within my time and budget constraints. There were very few dependencies on our own internal resources and indeed most of the Tech team had little knowledge of the project. I did pull in our heads of Engineering and UX to help keep me honest and on track.

Timing the project deliverables

As part of the scoping effort, I created schedules for each project that would produce results in a meaningful timeframe. Our next major product release had already been scheduled to coincide with an upcoming industry event. We already had plans to show off the latest product improvements at the trade show but if some of these R&D projects panned out, we would have even more to entice customers and partners.

The impact

Based on this preparation, I was able to get my R&D projects approved, funded and launched successfully. The early evidence is mostly positive and we seem to be on track to deliver on the goals I set early on. Now I'm engaged in some early internal promotion around a few of the projects and have even started to leak some preliminary results to our CEO and our head of Sales to validate the intended ROI. I'll share more progress updates in the weeks ahead.    

Look for more reports from theProductPath around product strategy, roadmap planning, and product investments 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