Great content is the best sales tool in the world.—Marcus Sheridan, author, The Sales Lion blog
A marketing director shared a new video series that she had prepared for the sales force. She was proud of the work but annoyed with the sales people. Seconds after publishing the videos, a sales person asked if he could share the internal videos with his clients.
She complained to me, “Every time I create something for internal use, the sales people want to share it with clients!”
She needs to listen to what they’re saying. What they’re saying is they want more sales tools and less sales education. More stuff to share with clients and fewer focused on training the sales people.
A product manager once asked me to authorize five days for sales training. “Surely I heard you wrong,” I said. “You must’ve meant five hours, right?” Nope. The product manager wanted five days. His agenda began with “Day 1: The history of computing.” Clearly he was trying to teach his lifetime of knowledge. But what do the sales people really need to know?
I’ve often remarked that it’s vastly easier to sell products when you understand them deeply. Everyone needs to know what we do here. And in my experience, the best sales people are ones with domain knowledge… but it’s their ability to apply that knowledge to customer scenarios that creates success. The best sales people are trusted advisors to their clients. And that’s the way it should be.
What do your sales people really need to know about your technology? They need to understand target markets and personas, and the problems your company can solve. Do they need more?
That’s why I emphasize sales tools more than sales education. Create ready-to-share sales tools for everything. Create ROI calculators, ebooks, white papers, slide decks—all ready to use and ready to share. Limit the number of confidential and internal-use documents to roadmaps and competitive battlecards.
The ideal sales tool is a container for your expertise—in business, technology, market, and domain. And then every sales person can distribute your knowledge directly to the client.
Listen to your sales people. If they want to share internal documents, they’re telling you they need more external documents. Respond to their requirements. They’ll be more successful and so will you.
About the author
Steve Johnson is a recognized thought leader and storyteller within the technology product management community. As founder of Under 10 Consulting, he helps product teams implement strategic product management in an agile world. Sign up for his newsletter and weekly inspirations.
by Rajat Harlalka
When building the mobile interface for their existing products, Product Managers are faced with quite a few perplexing questions, especially related to the user experience on mobile. A report from ZDNet says UX is one of the most critical concerns for enterprises looking to develop mobile apps while another study points out that users prefer usability and good user experience over brand names.
Before going deeper into the topic, let’s define what User Experience is. User Experience is not only about visual design. It is actually much broader — it involves the scientific research of users and can answer important questions about the audience for both new and existing products. These include:
- Who are your real users and what do these real users care about?
- How do they actually interact with your existing product?
- How will users interact with a new version or new feature?
Mobile UX patterns are different than desktop UX patterns
While there are several UX design best practices from the desktop world that can be brought to mobile, this piece focuses on mobile specific issues.
The foremost thing to remember when building a mobile interface for your product is that while mobile UX design has similarities with web and software design, simply stripping down your desktop or web experience is not going to do it. While drilling down is fine on the Web, mobile users tend to act more linearly a mobile application. To design a good app, you need to start from grounds up, identifying the customer experience you want, and enhancing it with the right features of your existing product. Great mobile apps are uniquely mobile, they couldn’t be done the same way anywhere else.
Follow the device’s native design patterns
When choosing whether to design for brand or device, put your preference on device. Your users have been using the device well before they start using your application. Developing custom interfaces will confuse users, slow down adoption, and put a significant obstacle in the way of engagement. Instead, take the principles of the OS-native interface kit, and subtly style your interface elements without altering the underlying functions.
A classic example is the Password Engine iPhone app. iPhone users are used to certain ways to access settings or placement of the Back button. By not following them, the app increases the learning curve for users.
Mobile application use is interrupt driven.
Mobile apps will always be subjected to interruption, whether by an incoming call or the user’s station arriving. Design your applications such that it is easy for users to pick up from where they left off - save states, break larger tasks down into smaller chunks, and put context throughout. Usually users on mobile will on the move, and hence subjected to lots of distractions. Organize content in a way so that it is easy for consumers to browse through.
Compare these two login screens.
With the Gmail iPhone app, all the fields and Calls to Action (CTAs) are vertically aligned on the left side and thus the user’s eye needs to move in one consistent direction.
Now compare that with the iPhone app from eFileCabinet which forces the user’s eye to scan all around the screen. It has less CTA’s and hence a lot of the real estate on phone screen that could have been better used.
Use mobile application data to benefit the user
Mobile devices generate a lot of information about the user apart from the traditional data generated from a web solution. This includes things like movement, location, sensor data etc. Think about using this data intelligently to pleasantly surprise the user. Customer satisfaction is great but customer delight is even better.
Yelp has recently updated its Nearby feature that now offers suggestions based on user’s location, previous Yelp check-ins and reviews, and Yelp friends as well as other data like the time of day and even the weather. This is a great update because it allows Yelp recommendations to be truly contextual. On a cold morning, it can recommend a good coffee shop while on a sunny day it can point to ice-cream parlours near you.
Know your device’s limits
And finally, understand the limitations of mobile devices – constrained hardware resources, screen size and network bandwidth. Consuming too much power or designing buttons for cursors rather than fingers and thumb will lead users to delete your application. Prioritize and present core features from other channels that have especial relevance in a mobile environment and enable mobile users to navigate to the most important content and functionality in as few taps or key presses as possible.
Measuring UX Performance
Like any product feature, you need to constantly measure UX and keep improving. A couple of ways to measure UX are:
Identify some of the key KPIs for your app. Example of some of the common ones are:
- Adoption: Track data such as DAU or 7 day actives
- Retention: Analyze the users who are coming back
- Engagement: Number of visits or time spent are good indicators of engagement
- Task Success: Use the funnel analysis to figure out dropouts
2. Usability Test
Observe users using the product. Ideally, you would compare these usability tests to ones done on your prior product. Does the new design achieve the intended goals, such as being more intuitive and driving users towards specific actions?
A great resource to start learning about the UX principles for mobile is the iOS Human Interface Guidelines. Another great resource for learning the basics of iOS UX and UI is Tapworthy: Designing Great iPhone Apps
by Josh Clark. Android too has a few Design Guidelines, and it is always good to have a look at them when developing apps for Android.
The mobile user experience encompasses the user’s perceptions and feelings before, during and after their interaction with your mobile presence. Creating mobile user experiences that delights a user forces us to rethink a lot of what we have taken for granted so far with desktop design.
Mobile user experience is still a developing field, and opportunities for improvement continue to emerge. By dissecting the mobile user experience into its key components, and placing the user’s expectations at the centre, we gain a conceptual framework for building and evaluating good mobile experiences.
Tweet this: Approaching Mobile UX – A Product Manager’s Perspective http://wp.me/pXBON-3UG #prodmgmt #mobile
About the Author
Rajat Harlalka has over 8 years of experience in the mobile industry in different roles – technology, strategy and product management. He has worked with companies such as Marvell, ST Ericsson and Exicon etc. and is currently a Product Manager developing mobile educational games and apps. You can find him on Twitter @RajatHarlalka.
by Emily Hossellman
Beta testing is a key part of product development, but it can be difficult to get the timing right. Product teams are often pressured to get new products through beta and out the door as quickly as possible, but if a product goes into beta too early it can defeat the purpose of running a beta test altogether.
As you get closer to running your beta, there are three distinct components that need to be ready: your product, your team, and your testers. If any of these areas are out of sync or under-prepared, your beta will most likely suffer. When they come together, however, they can enable higher participation, easier management, and better results.
The general standard for beta product readiness is a stable, feature-rich (although not necessarily feature-complete) product. If you give beta testers a very buggy product, you’re likely to see a flurry of initial activity — comprised primarily of redundant bug reports — followed by a major drop off in participation. Beta testers expect that the test product will have some issues, but there’s always a tipping point after which they’re too frustrated to keep trying.
Product Readiness Checklist
☐ The engineering team has verified that all of the components of the product are ready to begin beta testing.
☐ Auxiliary components (documentation, etc.) have been assembled into a single package which represents exactly what will be given to testers.
☐ The out of the box experience has been completely reviewed, including setup, installation, and supporting documentation.
☐ Basic product functionality has been thoroughly reviewed (all key features are working) by product management.
☐ Known bugs that could not be addressed prior to beta have been clearly documented and communicated to testers.
☐ The uninstall process has been successfully verified.
The second piece of the puzzle is making sure that your own team is ready. When it comes to beta team readiness, you’ll want to be very systematic and detail-oriented. It can be challenging at times, because you’ll often be managing your own immediate team and interfacing with stakeholders in other departments (and sometimes other companies). It’s worth the effort, though, since a beta test can easily veer off course if one of those stakeholders isn’t up to speed on responsibilities or schedules.
Team Readiness Checklist
☐ Core parameters and processes (e.g. testing goals, strategies and mechanisms for collecting feedback, categories for bugs, incentives, etc.) have been defined and communicated to all stakeholders and contributors.
☐ Milestones and deadlines have been communicated and understood and all necessary resources are readily available.
☐ Stakeholders have delivered all pre-test deliverables (e.g. tools, documentation, surveys, packaging, product keys, NDAs, beta units, etc.).
☐ Contingency plans have been defined for any stakeholders with limited availability (e.g. planned vacation, potential birth of a child, etc.).
☐ Any infrastructure that will be relied upon during the beta (beta test management tools, customer support, bug tracking, content delivery, servers, etc.) is accessible and has been tested.
Once you’ve handled product and team readiness, beta tester readiness should be fairly straightforward. The key here is to make sure that your tester sites aren’t just willing, but are also ready and able to test. From there, your responsibility is to make sure nothing is inhibiting their participation for the duration of the test.
Tester Readiness Checklist
☐ A sufficient number of sites and testers meeting each required target market segment have been selected and notified.
☐ Accurate contact information and addresses have been verified for all sites and all testers at each site.
☐ Non-disclosure and beta participation agreements have been explained in plain English, signed, and submitted by all testers.
☐ Responsibilities and the project schedule have been clearly communicated to testers.
☐ Testers understand how to use the systems provided for feedback. If they aren’t dead simple, training or documentation has been provided.
☐ All resources needed by testers to carry out their responsibilities are accessible and easy to understand.
While the ideal beta readiness guidelines for your product may vary from what we’ve discussed
here, hopefully this will get you thinking and planning, which is really the best defense against the uncertainty that precedes a beta test. Accept that certain things may be beyond your control, but meticulously plan and prepare for everything else.
In my next article, I’ll tackle what to do if your beta period is coming up and you’re not ready for beta.
Tweet this: How to Know When You’re Ready for Beta http://wp.me/pXBON-3U5 #beta #prodmgmt
About the Author
By Saeed Khan
It’s been several months since the news of Marissa Mayer’s INTERNAL memo on working from home, entitled “Physically together” became public. I had written a blog post in response to it, but decided that I should wait a while and let both the news sink in and my emotions settle before actually posting it. I didn’t expect it to be almost 6 months later though.
There’s a key section that memo that I want to focus on:
“…From Sunnyvale to Santa Monica, Bangalore to Beijing — I think we can all feel the energy and buzz in our offices.
To become the absolute best place to work, communication and collaboration will be important, so we need to be working side-by-side. That is why it is critical that we are all present in our offices. Some of the best decisions and insights come from hallway and cafeteria discussions, meeting new people, and impromptu team meetings.”
My remote worker story
The reason I wanted to write a response to that memo is that I am a remote worker. I have been for several years, and even when I wasn’t a remote worker — i.e. I worked in an office with others — I worked closely with people who were remote — relative to me at least.
Back in 2003, I worked on my first project with remote developers in India. In fact, at the time, I was working on the first product being remotely developed at the company I worked at. So there were a lot of eyes on us to see how it went. On this side of the world, I had a great development architect and development manager with whom I could discuss ideas, brainstorm, complain to etc. On the other side of the world, we had a corresponding development manager and a small development team.
After some initial missteps about how specific the requirements needed to be – the first prototype required a complete rewrite — we moved forward and worked very well together. I got used to waking up in the morning with various emails that arrived overnight, and I also got used to the weekly 10 PM Wednesday status call. And strangely, I also got used to working with people I never met face to face in my life, but with whom I felt a real connection and bond as we worked on several releases of the product.
Ten years later, I still work with an offshore team, still have weekly status calls, still receive emails overnight, and still have not met face-to-face with many of the people I work. In fact, I work closely with people both near-shore and offshore and meet goals and milestones, deliver successful product releases, participate in product launches etc. and see people once, maybe twice a year if that.
Culture and Communication, not Co-location
For me, being “Physcially together” to create successful products has never been an issue. It wasn’t necessary 10 years ago and it isn’t necessary today. The reason is that then, as well as now, its the culture that makes it possible. The work culture is about “getting things done” and moving forward. Clear and honest communication is necessary as is a sufficient level of patience as there are times where we cross-paths or have to repeat discussions or revisit decisions that we’ve made before.
But this would be no different were we all in the same room or building working together. I’ve seen huge foul-ups happen with people who work on the same floor of the same building, so co-location isn’t a solution for poor communication or poor culture.
I’m pretty sure Yahoo has some extreme culture problems and one way to trim some of the bad apples is too force those who take advantage of working from home to show up and step up, or leave.
There clearly are times where I miss the ability to sit across a table from my co-workers and have a brainstorming session on a topic, or catch up on some (not quite) unrelated developments happening in another product group. There is HUGE value in those ad-hoc discussions that happen — as the memo states — in hallways and cafeterias.
In the end, it’s very difficult to change the culture of a large, slow moving company that doesn’t innovate. Yahoo bought Flickr — an amazing photo-sharing app built by a small and talented team (of Canadians mostly!! ) and did virtually nothing with it. This has been the story with many such acquisitions — the most famous of which (in my view) was the $5.7 billion paid for Broadcast.com in 1999 — that made Mark Cuban an instant billionaire. Cuban has done a lot with the money he made, but what happened to Broadcast.com? Not much.
I predict that not much will happen with other Yahoo initiatives — and this is not a slight against Ms. Mayer — because changing the culture at Yahoo to one that creates great products will take a radical change of how the company functions and how the company is structured, and it’s unlikely that any CEO, Ms. Mayer or others, would want to make those changes. It might upset shareholders.
And don’t forget about Microsoft
BTW, Microsoft is currently going through their own changes (more sweeping than Yahoo’s) , trying to recapture their mojo. I’m sure I’ll get this wrong, but I think Microsoft will see real success before Yahoo does from those changes. It will be interesting to track both. What are your thoughts?
Tweet this: Remote workers, Yahoo and building great products http://wp.me/pXBON-3NQ #yhoo #culture #innovation
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.