Listening Labs
Not sure how many of you out there have been a part of usability studies or testing. My personal opinion is that “studies” put people in contrived situations and expect them to yield real-world data about how they are interacting with products.
This research is inherently faulty. Why? Namely because when asked, the natural response is for people to tell a researcher (or “expert”) what they think they want to hear.
Funny enough, Harry Beckwith covers this very, very well in his book The Invisible Touch.
I just watched one of Robert Scoble’s early interviews at his new FastCompany.tv gig with Mahalo founder Jason Calacanis. It’s not secret I’m a big Jason fan, and I think the Mahalo product is outstanding; in fact, it has replaced Google as my homepage.
The whole interview (parts 1 and 2) are really worth watching. However, about 13 minutes in to the first segment, they interview Mahalo’s Director of User Experience. He talks specifically about what i started this post discussing. His insights about what Mahalo does are fascinating - check it out:
To follow this up, Eric has created a Mahalo page with his insights and information about user testing. This is fascinating stuff, and I hope it can bring some additional depth to your product development process in the future.
Don’t Get Paralyzed
One of the most important things about getting products out the door is being able to call it and…actually get it out the door. The tough part about doing that is not letting yourself become paralyzed by whether or not features are perfect, or competitors have already released them, or they have all the bells and whistles.
The key thing to answer is: does the feature solve a problem? Keep the requirements true to that problem and don’t waver. A feature will never be perfect. There is no such thing as a “silver bullet.” Or, if you believe there is, you can’t rely on them. Make sure you do the work to align features being implemented with your roadmap and go heads-down on them.
One of my best friends Cory taught me about analysis paralysis when I was just starting out in my career. It may sound like something totally cliche, but it happens all the time. PMs must not be afraid to push through this and draw the line. If you don’t have a ton of user data coming in, don’t get discouraged. Someone has to make the call or else things will never really be done. You’re expected to keep the product glued together as you go - not everyone can see this like the PM, and it’s not their job to do so.
Sure, large features can be implemented in stages. Of course. No one should expected anything less. You never get it all in or totally right the first time. But what you can absolutely nail is the fundamentals and actually executing. Does it add value? Is it aligned? Does it have the fundamental capabilities it needs to? Is it usable and clear? If all answers point to “yes” then you have nothing to worry about - just get it done and release it.
Maintain Your Focus
Here’s a great little bit from Manage It, by Johanna Rothman…this book is highly enlightening and it’s great to know I’m not the only person thinking some of these things.
I once worked for a company that decided aftear a several-day offsite strategy meeting that we were going to “focus on five.”
That isn’t focus.
Focus means to center all of the attention toward something. Five strategic areas are four too many.
Unfortunately, it’s all too common for companies to spread themselves too thin in order to be all things to all possible customers. If that’s the problem where you work, move to short iterations as quickly as possible so you can say to your management, “OK, we can start that next week, because we’ll be finishing this in two days.” Even better, make sure your iterations start and end in the middle of the week, such as a Wednesday. That way if your managers have “a-ha” ideas over the weekend, they’ll probably give you a couple of days to finish what you were doing.
Your team will thank you for maintaining focus.
Stay the course, folks.
If that course includes too much stuff, either strip some of the dead weight, or move on.
Starting Out with Objectives
I’ve started implementing a set of key objectives and associated metrics with the product team. This is a fun process - especially since I have had the opportunity to take part in corporate-level planning with the management team for 2008.
This gives me the ability to do something very important - ensure everything is aligned.
Since this is happening within the company for the first time, it’s crucial that what’s setup is flexible but still effective. And the team is involved. It’s so important to remember that while you are a manager of a team, you aren’t a dictator - everyone needs to truly believe in what’s happening.
Plus, you’ll never slam dunk something like this on your own. It’s always better to gather feedback; especially if you’ve built a team the right way. Everyone will be smarter than you, so they’re going to be able to point out where you’ve mis-stepped and how something can be made better. But, I digress.
So, the question still stands: where to start with objectives?
It’s a pretty easy process really. To me, the thing that makes the most sense for a product team is to want to build market-driven products. That’s a pretty solid objective - ensure you are building market-driven products.
If it seems like this is too hard to measure, it’s not. While there are several checks and balances you could put in place, keep it simple. Remember, even if you aren’t in a start-up, you don’t want your team (or yourself, for that matter) to waste a bunch of time entering metric values for your ongoing management or Board of Director reports.
So, how can you tell if you are building market-driven products? While, first, you want to make sure the product can get customers and keep them - customer retention. If you can’t land customers it’s either a problem with Sales, product or both. Since we are talking about product management, let’s assume it’s a product-level issue.
However, it’s key to remember this isn’t all about killer features. If you are losing customers at a nasty rate, you can make sure of a couple of things:
- Has the product grown stagnant between releases?
- Is the market responding to product pricing?
- Is client support and/or implementation a concern?
- Are market needs being identified and met?
Now, market needs also include defects. If you have a slew of bugs, you may want to think about holding off on the new features for a while and do a bug release. It seems tricky, and maybe complex, but it’s not. Make sure if you find defects, especially those that are high severity, you’re fixing them. Make sure you’re gathering and paying attention to market data and implementing the right features.
The other metric you may want to consider is the cash flow of the product. You can ascertain this by looking at a basic product P & L. Is your product costing more money to develop than it’s bringing in? If it’s an intentional loss leader, than that may be OK, but if you are dumping tens of thousands (or more) of company dollars into each release and nothing is being yielded by customers in return, you can question the following:
- Is the product priced appropriately?
- Is the product positioned to take advantage of the right market opportunities?
- Are product release cycles taking too long?
- Is there a large number of high severity defects hampering product operation?
If people are buying your product, and you are bringing in positive revenue per release cycle, it’s addressing the right market needs. If this isn’t happening, and it’s not identified as a loss leader, it’s time to look at whether its positioned correctly, targeted appropriately, and being sold the right way and for the right price.
These are pretty simplistic, and I’m sure there’s a lot more than could be used. However, I’m a fan of the basics. If you want to be market-driven, make sure you can get and keep customers, and people are willing to pay for your product.
Making a Huge Company Agile
Want to know what it takes to make a company - like, say, the size of General Electric, or Wal-Mart agile? Look no further than how Jack Welch ran things when he was the CEO of GE for over 2 decades.
I just reading through one of the great books he’s put out, and here are some interesting highlights:
- Embrace Change, Don’t Fear It
- Face Reality, Then Act Decisively
- Don’t Focus on the Numbers
- Be Lean and Agile Like a Small Company
- Tear Down Boundaries
This is really interesting to me, because as a company grows, folks tend to want to start putting in more process and layers of management. While I’m not against having effective process points, I like to think of things more like a framework so people can make their own decisions. Also, creating leaders that are driving home key parts of the business is imperative.
I try to keep my philosophies grounded around similar fundamentals. Not just in product management, but in constantly trying to improve my skill set and contributing as much as possible to the company being successful.
Bring in people that are just really damn good. Provide the tools and skills to help others become really damn good. It’s not beyond a successful leader to do so.
Ensuring that people don’t feel tethered to do whatever “senior management” wants is crucial. Great ideas really can come from anywhere in the business; making sure they are being heard is necessary in order for a company to become truly great.
Being so closely tied to product, it’s easy for me (and others) to become really wrapped up in “roadmaps” and “features” and “action items” and “metrics.” However, while these things can be sexy to talk about, they aren’t the fundamentals of a successful organization.
What’s the most critical part of defining a new product? Identifying the problem that product is going to solve. The same goes for a business.
Identifying the vision for that organization and the objectives that need to be met is 100% critical. Everything else will come after that, including some amazing / lightning bolt ideas. But, everyone has to be dialed-in to that vision. It can sound like rhetoric, but it’s really not.
