Product Management – It’s All About the Execution

By Josh Duncan

doneI recently was asked, what are the most important skills for a product manager?

I answered that there are range of skills that a PM is required to use from the standard technical and business side and to the important soft skills like communication and persuasion. I have been thinking  more about the answer and think you can call execution the most important skill when it comes to Product Management.

Getting product out the door is one of the many metrics a product organization tracks and the product management team plays an essential leadership role here (see point #5 on Hiring a great product leader). In order to make this happen, a product manager has many responsibilities and tasks that need to be addressed. However, execution is not just about getting things done. Product managers usually have an endless list of action items that they need to address.

A few of the factors that product management must balance when prioritizing this list:

  • What are the company goals for this year?
  • What about next?
  • What are the development capabilities and backlog?
  • Where does sales need help?
  • Where is the services team experiencing the most pain?
  • What is the customer feedback saying?
  • What is the customer data saying?
  • Where is the competition at and where are they heading?
  • Are there market dynamics that need be taken into account?

Execution is about understanding what needs to be done and how to get it done given the current set of constraints. It’s about figuring out what is important, what’s not, and then making sure it all happens.

An effective product manager must be able to see all parts of the equation while prioritizing everything that needs to be done. It may be a meeting with marketing to align on outgoing messaging. It may be working with sales to finalize pricing changes. It may be design sessions with the development and UX team on the next big feature release. The key being that not everything that is important is most important right now. 

Execution is about getting the right things done at the right time resulting in the right product shipping on time. 

What do you think?


Tweet this: Product Management – It’s all about the execution #prodmgmt

Want insights? Go outside and observe!

By Saeed Khan

I returned recently from a business trip to Germany. Whenever I travel, whether for business or pleasure, I find it difficult to take my “product manager”  hat off. Little things catch my eye, and often seemingly mundane things such as efficient parking lots draw my attention.

Here are few observations and lessons from my trip that I’d like to share.

If at first you don’t succeed…

Back in January after a business trip, I wrote about an ad I saw in the airport promoting Accenture. The image is below.


The misspelling of word “Billions”, simply to fit the concept was what really irked me. As I was walking through Frankfurt airport last week, I saw another ad from the same campaign.


The German text at the top (“Wir haben uns…”)  is similar to the text in the English ad:

After studying the critical elements of Dow. The result: savings of 2.5 billion U.S. dollars

[Feel free to give me a better translation if possible. This is a modified version from what Google translate provided.]

I’m assuming “Woo Hoo” translates into German as it does in English. This ad is a bit better (IMHO) than the English version above.The “Woo Hoo” catches the eye (much more so than “BiLiONS”, and there is a hard fact — 2.5 billion in savings — embedded in the message.  Perhaps the German market is more discriminating or their agency learned from their misstep in North America. Not a great ad, but certainly better than the English language one.

BTW, if you want to see other Accenture (English) print ads,  you can see them here.

Tailor your messaging to your audience


While waiting for the subway in Frankfurt, I started reading a poster for movies playing in town. “The Return of the First Avenger” caught my eye. In North America, this movie is called “Captain America: The Winter Soldier”.  Not a great name in my opinion unless you read the comics and know the story already. “The Winter Soldier” sounds like a description of Captain America himself. But I digress.

Apparently, the title didn’t test well in Germany, so they went with the alternative title. It’s interesting though that they didn’t call it “The Return of Captain America”.  The first film used “Captain America” in it’s title in Germany. i.e. “Captain America: The First Avenger”.  Regardless, it’s one of the very few countries in where the name “Captain America” doesn’t exist in the title in some form.

Keep the messaging simple

I’m a big fan of clear and easy to understand messaging. It sounds like a no brainer that everyone should follow, but somehow, in the bowels of marketing meetings, often very simple concepts turn into nebulous concepts that mean little to the target audience. So it’s nice to see examples where that didn’t happen.

In Heathrow Airport, whose waiting areas are often hard to distinguish from shopping malls, I had to take note of this establishment. No fancy name or confusing signage. Just a clear statement written from the customer’s point of view. And with throngs of multilingual customers passing by, there is little room for confusion, even if you don’t speak English. I ended up buying some food there: soup, sandwich, drink – what more could a hungry traveler need?

eat store

Measure and manage where possible

heathrow security

And lastly, after I had passed through the security check point in Heathrow, I came across this device.  I guess Heathrow Airport wants to know how they are doing with their security checks. The simple interface – 4 buttons – Very Happy, Somewhat Happy, Somewhat Sad, and Very Sad — is easy to understand and doesn’t provide a middle button – i.e. ambivalent or no preference.

There is also a paper form that asks for more detail — Tell us how we can make your journey better. I regret not taking a copy of one of those forms just to see what they were asking inside.

I did see one person walk up to the device and press a button so people do use it, but few people overall were pressing the button. This device was sitting near the exit of the security area and no mention of it was made via signs or security staff previously. If the security officers simply asked people to give them feedback as they via the device, there might be a higher response rate.

Still, it’s a start. I’ve not seen similar devices in any other security checkpoints in any other airports.

So there you have it. There are lessons we can learn everywhere. All that’s needed is a trip out of the office.


Tweet this: Want insights? Go outside and observe! #prodmgmt #insight

About the author

Saeed Khan is a founder and Managing Editor of On Product Management, and has worked for the last 20 years in high-technology companies building and managing market leading products. He also speaks regularly at events on the topic of product management and product leadership. You can contact him via Twitter @saeedwkhan or via the Contact Us page on this blog.

Dear Product Manager: 4 Things Your UX Expert Wants You to Know

By Heather Searl

Dear Product Manager,

Here we are at the start of another project and, while I love working with you, there are a few things I’d like you to see from my point of view.

First off (and this is a biggie), you are NOT the target user.

Postcard representing a letter to Product Managers from UX

I know you know our domain inside out, and the presentations you give about the technology are impressive. I know you are passionate about our product and that you live and breathe everything related to our domain.

The problem is you know, and care, too much. Most of our users are not as passionate about our products as you are. Yes, I know there are some and I know they sought you out at the last user forum to share their ideas with you.

But most of our users aren’t like that. They use our product to accomplish a goal so they can move on to the next thing. They don’t understand all the industry jargon that rolls off your tongue with ease, and they don’t care about all the flash and wiz-bang of the latest and greatest technology advances.

My point is that we can’t design a product that is perfect for you.  We need to design a product for the typical user.

Secondly, you can’t do it all.

Yes, you are ultimately responsible for the success of this project and that’s a lot of pressure. I understand why you want to talk to all of the customers, document all of those discussions, analyse the results, and decide what tasks to use in usability testing. I get that you want to make sure everything is done right, but you can’t do it all.

You have too many budget meetings to sit through, sales projections to compile, stakeholder suck-up lunches to attend, and a million other things that have to be done as part of your day.

Let me help.  I know that it takes as long to write up the summary of a customer interview as it does to do the interview. I’ve done it many times. I also know that if it isn’t done that information will be lost.

I’m not suggesting you hand over all of the customer insight activities to me. Oh no. You HAVE to be part of that. It’s crucial that you understand our users inside and out. Which kinda’ brings me to my next point.

Third, you and I shouldn’t be the only user experts on the team.

I know it’s in your job description and mine that we talk to end users and understand their needs. But the developers, QA testers, tech writers and everyone else will make better decisions if they fully understand the user’s needs as well. Let’s take some of them along with us on our next customer visits, and after that, let’s put together some lunch and learn sessions to share what we learned with everyone else.

Yah, I know we’ll have to drag some of them (especially the developers) with us kicking and screaming. But I promise they’ll come up with some great ideas when they are working with firsthand knowledge of our end users instead of making decisions by guessing at what end users do and don’t do with our product.

And lastly, please, oh please, focus on the WHAT and not the HOW.

For example, don’t create full wireframes for your concept and requirements documents. These documents should tell us what to build, not how to build it. When you put too much detail about how things should look and work into these documents you lock us into a design direction when the project has barely started.

Put together some high-level sketches so everyone can visualize the product – but don’t go too far.  Some of our teammates are pretty literal, and they are going to fight against every change to your original idea no matter how much sense those changes make.

If you are worried that I or the rest of the team will go off on a tangent with the design, don’t be. We WANT you involved in our brainstorming sessions and we WILL get your approval on all designs.

Speaking for myself, if I don’t do detailed design reviews with you or I don’t give you time to think about the workflows and interactions that I’ve put together, call me on it. This is a collaborative project after all.

Please understand that I’m not pointing these things out just to make my job easier (although that is part of it). It’s more about working as a team. The more in-sync we are about what our users need, and the more we understand where each of us is coming from, the stronger the end product will be.

Let’s talk. In fact let’s make sure we are talking a lot more than we are now.


Your UX Expert

Tweet this:  Dear Product Manager – 4 things your UX expert wants you to know #prodmgmt #ux


Heather is a user experience consultant and writer who believes in doing everything from a user-centric point of view. She has more than 20 years working in high tech and is well-versed in helping product management and development teams get to know their customers, understand usability issues and turn these insights into design ideas and innovations. Heather can be reached at or on Twitter as HeatherSearl.


Photo courtesy of  Jeanne Menj via Flickr

Product management in the Cloud

by Paddy Barrett

How the shift to SaaS product offerings changes the role and activities of the product manager.

paddycloudA product manager who has learned the craft with on-premises products will have to adapt to the cloud by becoming more flexible and responsive – flexible in adapting to the speed of change with cloud products (think continuous delivery) and responsive to the greater interaction with customers that the cloud allows.

These were among the main findings of my dissertation for an MSc in Software Product Management in which I set out to determine the impact of the shift to the cloud on product managers. The existing academic literature revealed that little or no research into the subject had taken place, even while cloud computing was gaining more acceptance from business users, and as more enterprise software vendors were entering the cloud space.

Such a seismic shift in the industry was bound, I believed, to have a significant impact on the role and activities of the product manager, so I set out to research the subject by interviewing practising product managers who had experience with on-premises and cloud products.

To find suitable candidates for interview, I reached out to Scott Sehlhorst and Rich Mironov, who were guest lecturers during my first year of the Master’s program. Both were kind enough to introduce me to their contacts, and in the end I had to decline several offers to participate! The interviews covered the following core subjects:

  • cross-functional teamwork
  • decision-making processes
  • customer relationships
  • pricing
  • product life cycle management
  • continuous release
  • new product development
  • and key personal qualities and skills.

Over the course of ten in-depth interviews, my research confirmed that the aim of the study was valid – the shift to the cloud has a concrete impact on the product manager, and this impact is seen most clearly in the areas of cross-functional collaboration, customer relationships, and innovation.

My findings also met other research objectives, such as identifying the different product management activities required for cloud products compared to on-premises products, and an appreciation of why cloud products require a different product management approach.

The management of cloud products differs markedly from on-premises products in terms of the responsiveness and flexibility required of the product manager – the adaptability of the product manager becomes a critical factor in the success of cloud products. The shift to the cloud affects several activities of the product manager, who must anticipate new demands on both the role itself and on related functions within the organisation. From this conclusion, some key recommendations for practice are possible, including:

  • Understand how the cloud model works, with special regard to legal requirements for data protection.
  • Foster customer loyalty and interaction by managing customer expectations.
  • Master the use of metrics to analyse how customers use the product and also to develop product requirements.
  • Introduce design thinking practices to improve innovation, engage with users, and test prototypes.
  • To prevent the customer disruption that can be caused by continuous release, give customers some control over receiving upgrades to the product.
  • Help your cross-functional teams to adopt better collaboration processes, such as social networking tools, for faster communication and decision-making.
  • Stay focused on your long-term product strategy to safeguard against the tendency to focus on short-term customer requirements.

Some of these practices probably require further study, particularly the management of the continuous release process, the new opportunities for innovation – especially design thinking – that are made possible by the cloud. Other areas that could benefit from new research include lifecycle management of cloud products, the use of social networking tools for cross-functional collaboration, customer relationship management within the cloud paradigm, and the migration of on-premises products to the cloud. Given that the interviewees were all operating in B2B environments, it would also be interesting for other researchers to compare the experiences of B2B and B2C product managers.

In conclusion, this research offered a new understanding about the impact of the shift to the cloud on product management. Specifically, it found that traditional product management activities become more dynamic in the cloud context and that the product manager must adapt by becoming more flexible and responsive. It also found that managing customer expectations becomes a critical concern for the product manager.


Tweet this: Product Management in the Cloud - #prodmgmt #cloud

About the Author
Paddy Barrett is a technical writer for IBM Connections and a budding product manager. He received his MSc (First Class Honors) in Product Management from the Dublin Institute of Technology last November.

Can marketing learn from agile?

By Steve Johnson

Failing to focus, failing to choose one discipline and stick to it, is exactly what leads firms to a state of mediocrity.—Michael Treacy & Fred Wiersema

small__5141328136When I was the head of marketing, I got into a heated argument about our marketing and promotion programs. It was in a senior management meeting of directors, VPs, and the CEO. One of the directors took me to task for not supporting more industry speaking opportunities. Initially, I gave him a non-answer so we could get back to our primary discussions but he wouldn’t let it go. “Tell me,” he demanded, “why we’re not speaking at industry conferences!”

I shouted back: “You’re getting all the marketing you can afford!”

I explained my approach. “We wrote down everything we wanted to do, put it in priority order, and then moved down the list until we ran out of money. Speaking didn’t make the cut.”  I continued, “Of course, we can do more programs when we have more money. Does anyone want to move some money from their budget to the marketing budget? I thought not.”

We now know this technique as one of the basic elements of Kanban. And yet, in my conversations today, I still hear sales and marketing people arguing about individual programs. “We need to do a newsletter!” or “Hey! Let’s write an ebook!” or “Why aren’t we blogging?”

It’s time to take a step back.

Marketing, like every other department, has to prioritize. We have to choose. And that usually means choosing not to do things. Invariably some don’t get their pet programs funded. After all, there are always more ways to spend money than the budget allows.

We can learn a lot from Kanban. Just like your home budget, you allocate funds by category, prioritize the list, start from the top and work your way through the list until you run out of time or money. We need to focus on business prioritization—just like agile development teams.

What if we managed the promotion plan like a product backlog? What if we applied agile techniques to marketing?

Think of your marketing programs in three levels: company, products or initiatives, and campaigns.

Start with your investments at the company level. There’s a big (or maybe not so big) pot of money. Allocate it among your products and initiatives. What are your big initiatives? What percentage should support the launch of your new products while maintaining the old ones? And don’t forget infrastructure and maintenance. How much do you need to spend on basic infrastructure, such as the web site, automation, and memberships?

With your percentage of marketing spend allocated by products or initiatives, write down your list of campaigns and promotions. Write down everything you can think of.

Now prioritize the list. Look at the business value of each item compared to the others. You can start with “this is more important than that” and after you have a rough sorting, look at the delta between current and desired state. That is, are there any items that are “good enough,” at least for now?

Consider using the Outcome-Driven Innovation approach to prioritization from Anthony Ulwich’s What Customers Want. It’s really quite simple. On a scale of 1 to 5, rate the importance of each item. Then, again from 1 to 5, rate the satisfaction with your current state. The value of the opportunity (or program in this case) is the importance plus the delta between importance and current satisfaction. Need help? Download this tool to see how it works for your marketing programs.

If you need help wrapping your mind around apply agile approaches to marketing, Lean Samarai has a quick video overview of the SAFe approach to product development. Watch the video—but instead of thinking how it can be used in development, consider its application to marketing programs. Instead of development teams, think of your content teams, bloggers, PR teams, events, and so on.

This approach makes sense to me. What about you? Does agile marketing make sense for your organization? Add your comments below.

photo credit: 3oheme via photopin cc

7 Ways to Ramp Up Quickly as a New Product Marketer

By Rahim Kaba

getthefactsAs a product marketer, you’re expected to be the “buyer” expert in your organization and clearly communicate how your products can benefit potential buyers. But if you’re new to your company and its markets, learning about your buyers isn’t straightforward; unlike other roles in your organization, you need to seek information from outside the company. Unless you’re moving into your new role from within the organization (or perhaps as an ex-customer), you probably don’t know a lot about your company’s buyers and markets.

Even if you have the right skills as a product marketer, you won’t be able to do your job effectively until you truly understand your buyers’ challenges and needs. Once you begin to acquire this knowledge however, you’ll be in a unique position to connect the dots between your buyers’ greatest pain points and your solutions’ benefits to persuade them to purchase your solution over the competition (or the status quo).

For new product marketers, the learning curve can be quite steep. So how do you ramp up quickly? Here are 7 practical tips to help you succeed in your new role:

1.       Don’t believe everything you read

Internal documentation is always a good start, but often only reflects your company’s perspective of its products and buyers. Dig deeper to get the full picture of what your buyers really want.

2.       “Listen” to the market

Register for daily or weekly Google Alerts and join LinkedIn Groups relevant to your industry to monitor what others (e.g., competitors, customers, industry experts, and analysts) are saying. This will help you spot trends and identify new and important topics of interest in the buying community.

3.       Gain insights from customer-facing employees

Your sales team isn’t the only group within your company that has a good understanding of your buyers. Take the time to talk to your pre-sales engineers, field marketers, technical support, and professional services staff to gain insights into what your prospects and customers think about your company and products. This will help you determine what they appreciate the most—characteristics that you may want to place front and center in your sales and marketing materials.

4.       Join sales calls and demos

Since you’ll be working closely with the sales team, it’s important that you attend sales calls to see what they’re up against on a daily basis. Not only will you learn how your sales team pitches your products, but you’ll also hear firsthand the challenges your prospects and customers are facing. After several calls, you’ll likely begin to see patterns that will help drive product positioning and enable you to create tools that will resonate well with your buyers.

5.       Talk to champion customers

Your company probably has customers that get overly excited about your products. Get introduced to them and ask about their biggest challenges, why they chose your products, and what your company is good (and not so good) at. It’s likely that other buyers in the market have similar challenges; use this information to showcase how your products can help solve their problems as well.

 6.       Attend industry conferences

Travel budgets are tight these days. But if you have the opportunity to attend industry conferences or events, don’t go just as an observer. This is your opportunity to speak to thought leaders and buyers, and gain valuable insights into your market. You’ll likely hear from buyers that are outside your company’s pipeline—enabling you to gain a wider view of market needs and trends, and provide valuable input to your product management team.

7.       Perform win/loss interviews

Get access to your company’s most recent wins and losses and talk to your buyers directly. You don’t need to be an expert on your products to have conversations on why they did or didn’t buy your products.  With 10 or so interviews under your belt, you’ll begin to see common buyer concerns and needs that will help shape your positioning and messaging strategy.

As a new employee, you know how important it is to quickly showcase the value you can bring to your company. New product marketers have it particularly tough because they have to acquire their expertise from outside the organization. Make sure you take a holistic approach and get insights from a wide variety of sources in order to paint an accurate portrait of your buyers.

If you aren’t being provided opportunities to become the buyer expert at your company, speak to your employer to get access to the right resources and tools. It’s in their best interest to help you succeed in your new role.


Tweet this: 7 ways to ramp up quickly as a new Product Marketer - #prodmgmt #prodmktg #innovation

About the author

Rahim Kaba is a B2B product marketing professional based in Montreal, Canada with over 10 years of experience managing successful products, services, and marketing programs in a wide range of industries and sectors. You can find him on LinkedIn.



If I Were Building the Ultimate Technology Solution for Product Management & Marketing…

By John Mansour

swiss army laser knifeIt’s been on my mind for years, even to the point where we seriously considered developing it at Proficientz a few years ago. But we decided to practice what we preach and stick to our core competencies, at least for the foreseeable future.

But the frustration level from our clients is reaching a fever pitch as they look for technology solutions to support product management and product marketing functions. Yes, product marketing too!

If I had to characterize the sentiment from our clients, they’d say the current technology solutions help product managers manage products, but none of them help the organization develop a stronger product management and marketing discipline.

Comments I hear most often:

  •  “They’re bloated with features and difficult to implement and use.”
  • “They focus on helping you manage whatever you’ve decided to do but none of them facilitate the decision process.”
  • “They’re all requirements management packages in one form or another.”

Perception is reality, so I feel compelled to start this discussion – and you’re invited to join the party – in an effort to get technology providers and product professionals engaged in a conversation on a very different level to advance the cause. I can’t imagine who wouldn’t benefit!

For as long as I’ve been in the product management and marketing profession, we’ve aspired to become the heartbeat of the organization, not for selfish reasons but to help our organizations reach their full potential. With the right technology solution, this goal becomes a chip shot!

Who’s Invited to the Discussion?

  • Product managers, marketers and strategists who need solutions
  • Your counterparts from the technology solution providers

The discussion will take place in the Proficientz LinkedIn Group only so please share this blog with your social networks and let’s see if we can generate enough momentum to benefit both parties.

Isn’t it time to put our heads together in ways we’ve never done before and use social media to do something significant for our profession?  Let’s make it happen.

Guidelines for the Discussion

Please use the following guidelines to keep the discussion engaging for everyone.

  •  Limited to B2B products and services.

Product Managers & Marketers Who Need Solutions

  •  Please focus the discussion on activities, goals and objectives and why they’re important to your organization (and not ask for features).
  • Please do not make references (good or bad) to any product or service providers you’ve had experience with.

Technology Providers Who Build Product Management & Marketing Solutions

  • Please refrain from promoting or defending your solutions either explicitly or implicitly.
  • Please do not encourage your customers to drop testimonials into the discussion.
  • Feel free to ask questions to clarify something.

Product Management Service Providers and Consultants

Remember, the purpose is to connect the people who need the solutions with the people who develop them. I recommend we sit on the sidelines and learn as much as we can from the discussion.

My role in the discussion will be a facilitator to kick things off and introduce topics that (in the eyes of our clients) never get any airtime on blogs or social media. All participants are welcome to do the same.

John Mansour

Tweet this: If I were building the ultimate tech solution for PMs and PMMs – #prodmgmt #innovation

About the author

John Mansour is a 20-year veteran in high technology product management, marketing and sales, and the Founder of Proficientz, a services company focusing on product portfolio management.



Help! I’m a secretary to development

Or, Why a developer can’t also be product manager

negativespaceIn small companies—and in some not-so-small companies—the development lead often serves as the product leader or product manager. Is this a good idea?

In your team, who is responsible for persona or market definition, requirements, acceptance testing, and feature prioritization?

Like a fox guarding the henhouse, the one who develops a feature should not also be the one who verifies that it meets the market requirement. Product features should be prioritized based on market need and not on available development resources. And the one who is managing the daily operations of product development is unlikely to have time for research on markets and their requirements.

Many product teams—and some executive teams—are confused about the role of product management. And often, this results in product managers who type up meeting notes, update spreadsheets with the team priorities, move “to do” items to the “completed” column—in short, they’re become secretaries to development.

One of the leaders of the Scrum movement told me that he’d never met a product manager he respected. Maybe that’s why today’s agile teams have a product owner instead of a product manager.

I met a developer once who said the key was patience. “I’ll be here long after the product managers are gone. I just have to wait them out.”

Back in the early 1980s, I joined a company in Dallas. This was my first vendor experience and it was one of the best-run software companies I would ever encounter, something I didn’t appreciate until many years later. This company had a very clear job description for those who performed business planning for a single product. The title: product manager.

Now jump to the late 1980s. In his seminal tech marketing book Crossing the Chasm, Geoffrey Moore recommended two separate product management titles:

A product manager is responsible for ensuring that a product gets created, tested, and shipped on schedule and meeting specifications. It is a highly internally-focused job, bridging the marketing and development organizations, and requiring a high degree of technical competence and project management experience.

A product marketing manager is responsible for bringing the product to the marketplace and to the distribution organization. It is a highly externally-focused job.

(Actually, this is still a pretty good delineation of product management and product marketing.)

In 1995, Ken Schwaber and Jeff Sutherland formalized the Scrum development methodology. And with it came yet another product management title: product owner.

The Product Owner represents the stakeholders and is the voice of the customer. He or she is accountable for ensuring that the team delivers value to the business. Scrum teams should have one Product Owner.

Developers tend to prioritize based on intuition while sales teams focus more on active deals in the pipeline. Others prefer to leverage their industry experience. Ideally, a product manager will employ these methods plus customer requests and quantified market data. Read more about the ways that companies make decisions.

Steve Jobs was famous for using his intuition on what the market needed; he generally ignored the advice of industry pundits. Marissa Meyer seems to use data to support her decision-making. But what can you say about Microsoft, Nokia, and Blackberry? Who did they listen to for insights on where to take their products? Did they listen to sales and development? Did they listen to the analysts and reporters? Or did they have meaningful conversations with their best customers?

Sure, there are many companies people use as examples, both good and bad. You can use Apple and Microsoft and Google and others to make almost any point you want to make.

Who in your organization should be making the business decisions about the product? Unlike some, I rely on development to make technical decisions; I want them solving problems. And I want product managers and product owners talking about personas and problems rather than solutions and capabilities. Product managers define the problem; product developers solve the problem.

Developers don’t need a secretary reading aloud from a requirements document; they need context about markets and problems that address a business need.

There is much more to a product than the product: there’s promotion, sales, support, operations. These are strategic decisions about the business of the product. Who in your organization is best suited to make these decisions?

5 Tips for Building Tablet-First Business Applications

tabletBy Rivi Aspler

Congratulations, you have just gotten approval to build a tablet-first business application.

This scenario is nothing new when your product has been designed initially for the mobile consumer, but is a professional dream-come-true for the traditional B2B Product Manager.

As always, talking the talk is easy. Walking the walk is a challenge. Not only are there very few best practices for building mobile-first B2B applications, but there are still very few business users who work on tablets for the majority of their day.

This post is an attempt to capture some of the growing knowledge of business mobile applications so that your product investments are utilized in the best possible manner.

1 – Expect Two Modes of Usage: ‘On-The-Go’ and ‘In-The-Office’

If your product handles heavy-duty tasks (good SW examples are Photoshop, SolidWorks and AutoCAD), then unlike traditional desktop products, the importance of a focused MVP (Minimal Viable Product) per resolution size becomes a critical decision.

You must define what tasks the target user will want to complete ‘On-The-Go’. For example, urgently addressing alerts or the handling simple but very common tasks that one can do without much attention to little details)?  Such features will go into the MVP-tablet application with a mobile UI (touch gestures, layered content etc.)

In parallel, you must assume that your users will connect their tablets to a large resolution screen for at least a few hours a day and certainly for the heavy-duty tasks. You must therefore define those heavy-duty tasks and make sure that they can be performed using a mouse and a keyboard as well.

2 – Carefully define your Mobile-First MVP (Minimal Viable Product)

If your B2B product is mature, module-rich, crossing verticals and internationalized, your tablet-first version will not be able to meet the needs of all geographies, all verticals, all types of users and all types of tasks. Making sure you are leveraging your limited resources effectively, you should decide which geographies, which verticals, which users and which types of tasks you focusing on first.

3 – Re-Design the Application to Fit Mobile UX Guidelines

Leverage the mobile-UX knowledge that has already been gathered and documented.  Good sources of information are: Android Design, your place for learning how to design Android apps or Designing for iOS 7  websites.

4 – Test your Product UX with Millennials

You obviously want to know if you are doing a good job with the UX design of the tablet-first application. Unfortunately a usability test with mouse and keyboard savvy people will not give you the results that you are looking for. They will not be happy with the UX unless it imitates the product that they already know.

Millenials are those born (roughly) between 1977 and 1992 – or those currently between 22-37. They are mobile and technology savvy,  they represent the upcoming target mobile users, and will do a great job testing your new UX.

5 – Sales Strategy – Throw in a bunch of cost-effective tablets

Tablets as an in-office tool are not very common yet. Don’t let it be a show stopper for your mobile first product. Since there are many types of cost-effective tablets out there, you should test multiple different tables. as well as the the software itself on those tablets.

Oh… and don’t forget, if you are building a mobile-first heavy-duty business application, you are amongst the first ones to do so. You are therefore bound to make some mistakes. Embracing the challenge as well as the frustration is a necessity.


Tweet this:5 Tips for Building Tablet-First Business Applications #prodmgmt #mobile

About the author

Rivi is a product manager with over 15 years of product life-cycle management experience, at enterprise sized companies (SAP), as well as with small to medium-sized companies. Practicing product management for years, Rivi now feels she has amassed thoughts and experiences that are worth sharing.

In case you missed ProductCamp Silicon Valley 2014…

by Saeed Khan

I had the pleasure of attending ProductCamp Silicon Valley this past weekend. Like all such events, it was good to see familiar faces and meet new people as well.

I had 2 presentations.

One was on my own, covering a topic near and dear to me — Lean Communications. The other was a town-hall discussion with my friends Steve Johnson and Barb Nelson. Steve regularly posts on this blog, and I’m trying to convince Barb to start. :-)  She’s a great Marketer and I think her stories and insights are worth sharing.

Steve also gave a talk on his own entitled – Has Agile Ruined Product Management? – which already has been blogged about by an attendee!

Additionally, my good friend and fellow blogger on this site, Prabhakar Gopalan, flew in from Austin to attend and he gave a talk — a reprise of his well received talk from the recent Austin ProductCamp — The Whole Product Manager: What it takes to be a Craftsman. Want to know what a sushi master in Tokyo can teach you about being a better Product Manager?  Read through Prabhakar’s presentation.

The following is a curated version of the tweets from the day. Will try to attend next year, and hope to see  you there.


Tweet this:In case you missed ProductCamp Silicon Valley - #prodmgmt #svpcamp

About the author

Saeed Khan is a founder and Managing Editor of On Product Management, and has worked for the last 20 years in high-technology companies building and managing market leading products. He also speaks regularly at events on the topic of product management and product leadership.

%d bloggers like this: