If you missed ProductCamp, check out the post-camp presentations and session notes offered on the ProductCamp Austin site!
Japan Rising: The Importance of Knowing Your Customer
Japanese women are bound by cultural norms that by Western standards may seem strict. Over the past 20 years, a trend has developed where as Japanese women enter the workforce, they are delaying having children to have a career, and are becoming more assertive about their wants and needs as consumers. As a Product Manager, this is an interesting test lab for finding new problems to solve, since new groups of potential customers don’t generally appear as quickly or as aggressively as the working Japanese woman.
CNN is running a short video clip about a fascinating new business catering to this demographic in Japan: overworked, under appreciated Japanese women who feel constrained by the rules and traditions of Japanese society and appreciate the freedom and empowerment of their Western peers.
In this restaurant, hosted exclusively by Western males, the servers dote on their Japanese clients, almost in a reversal of the old geisha tradition. The best part of the video is that the owner went out and interviewed 200+ women about what they wanted before investing in the concept. There is nothing special about the food or tiara offered to each patron - these women are buying on the service and experience that they can’t get elsewhere. This is a great way to keep costs in line while differentiating your product. Ikea is another example in a different industry.
How do you listen to customers to differentiate your business?
You Don’t Really Own Your Roadmap
Sales people hate looking stupid. Unfortunately, we often put them in positions where they look very stupid by changing plans and roadmaps, which is our own fault. How do you keep the trust of your team when your business, roadmap, and customers are shifting in the sands around you?
There are lots of reasons that plans change, some good and some bad: the Market shifts, the competition makes a play, or the company dosen’t hit its goals and has to layoff developers, which pinch your resources. All of these create a refactor in your roadmap.
There are several tactics you can use to lessen the impact of changes to The Plan. I’ve written in the past about the importance of separating your Roadmap from your Release Plan. This simple change, and the cultural impact at the Executive level down to the developer level of thinking that “a product/feature on the Release Plan is locked in and cannot be changed” is huge. Remember that Release Plan’s mean that the product or feature’s release is imminent and committed - your Release Plan should never cover >6 months.
Also, realize that you don’t really own your roadmap. The best you can do with the roadmap is plot a general direction for a product or service, but when it comes down to it, the Market and the Business own the roadmap. The Roadmap is not yours; you are the steward of the Roadmap. I see products and companies fail all the time because they set their roadmap and expected the Market to bend to them; it doesn’t work that way.
One-off deals can also derail the roadmap. In a smaller company where there is immediate revenue pressure, the allure of a special deal that “just needs this one feature” is huge. Are you ready to turn down a million dollars in revenue? Most Executive teams are not. Be able to illustrate how any proposed feature or product changes to your roadmap delay or eliminate your entrance into new markets or buying personas. That changes the special deal conversation from emotion-based to data-based.
New Development VP’s also have a tendency to take roadmaps off course. The reason: they love changing technology architectures. I carry a cross on this one since I’ve been burned before, from a CTO who changed the team from Java to .NET…which meant retraining some developers, dumping other developers, and hiring new developers. We lost 12-18 months just spinning - it was stupid!
When you see the VP of Development pushing for a change in development platform or underlying technology, drill closely into the details of why. Most Dev VP’s aren’t dumb enough to say “it’s because it’s a fad” or “because I want to get quoted in CTO magazine!,” and they will come up with legitimate sounding reasons why the old platform sucks and we really, really need this new one. You need to provide the voice of reason - with today’s technology, you can build an adapter to and from almost any technology without having to rip up your entire platform. If it’s that strategic to change your platform, the company should be able to justify the expense of building a parallel platform next to the existing one without disrupting current development.
One type of project that can be completely immune to external forces taking them off roadmap is the open source project. Since developers in this model often develop for themselves and not for the Market, oftentimes they don’t care what their users are asking for. Other open source projects are more flexible to the wants of their Market and do adjust their plans.
What other reasons pop up for taking you off roadmap, and how do you combat them?
ProductCamp Wrap-Up
ProductCamp was this past Saturday, June 14th, and I’m happy to call it a complete success. In almost every way, it exceeded our goals for participation (130+ signed up, 80-90 showed up), sessions (over 20 presentations and roundtables), sponsors (11 great sponsors), volunteers, and feedback. Nearly everyone I talked to was extremely positive about the event, and was looking forward to the next PCA. The consensus of the group was that they would like to do ProductCamp twice yearly, so we’re going to do just that.
If you missed ProductCamp, first I’m sorry because you really missed out on a great day of teaching, learning, and networking. Second, we’ve capture many of the presentations and session notes on the ProductCamp page for you to review. Here are some highlights:
- Charlie Ray won Best Overall Session for his presentation on “Navigating the Poltical Minefields of Product Management.” It was a really raucous and entertaining session, some choice quotes included:
- “Product Management is the most visible position in the company. People see you hanging out with the CEO and glad handing the VP of Marketing, and they want you to fail!”
- “You should be aware of which people are setting you up to fail so you can get them first. Always listen, and never give information, only take it.”
- “The hardest thing I do in my job is fake sincerity and pretend like I’m interested in going to your meetings.”
- John Milburn of Pragmatic Marketing and I hosted a standing-room only session on Startup Product Management, based on the webinar we did several weeks ago (based on the article we wrote for the Pragmatic Marketer). This fostered a really good discussion of the differences between PM in a BigCo and Startups. My favorite quote from the audience:
- “Startups in the Valley are hipster-based. Startups in Austin are geek-based.” The commenter was making a point in reaction to John saying that if you asked VC’s they would say that the startups in Austin are less focused and driven than in the Valley.
- Ben Phenix gave a User Experience session that people raved about on Twitter. Twitter was the surprise hit of the day to me - everyone was using it, and you could monitor the tweets as a backchannel discussion to gauge how the day was going. We set up a PCA twitter account that everyone could reply to.
- Tal Boyd of Seilevel and Paul Sizemore went around a took lots of pictures, which are now on Flikr.
- Graham Joyce of Pragmatic Marketing handed out their upcoming book entitled “Tuned In” (which I am almost done reading…topic of an upcoming post) during lunch to the person that had been in Product Management the longest (28 years, sorry Don), the shortest (1 week), and who traveled the furthest to get to PCA: Plano - we actually had several Dallas people make the trip, which was great.
I had lots of interest from PCA participants to help plan the next ProductCamp. If you’re interested in planning, please join the Google Group PCA-Planning. If you’re interested in participating in a future PCA and would like to be kept up-to-date, please join the general ProductCamp Austin Google Group.
My favorite memento was I had the PCA participants who lasted until the evening all sign one of the ProductCamp Austin sponsor boards that we had made. That will live in my office as a memory of a great day, and more great days to come.
Some final notes, in the post-PCA survey we sent out, we asked “Would you recommend ProductCamp to your peers?” 100% said yes (n=26). That says enough for me!
Thanks to everyone who made ProductCamp Austin a reality, and let’s get started on the next one!
ProductCamp is Today!
I am writing this from the “Dealing with Sales” discussion session at ProductCamp. It’s been an exciting day; lots of good sessions and very smart people. I will be updating the PCA wiki with all the session presentations and notes over the next few days. If you’re not here - you’re missing out!
How to Be Strategic
“You should be more strategic.” “Product Management needs to focus on the strategic.” “I’d love to be more strategic, if only I wasn’t stuck doing all of these tactical things!”
Do any of the above sound familiar to you? Being asked to be more strategic, or wishing to become more strategic has been around as long as someone called themselves a Product Manager, but what does it really mean? How can you become more strategic when everyone is vying for your time - all the time?
Strategic is a term that has lost meaning since it became part of the Executive lexicon. Everyone wants to “be strategic,” because in the information economy we associate the most value with the people who come up with the best thoughts. Being tactical is, amazingly, viewed as a negative. You can hear the connotation drip from people’s mouths when they say it: “Oh, he’s a good candidate, but I think he’s too tactical.” Everyone wants to be the chef, no one the waiter…as if the food will cook itself and walk out to our customer’s tables.
Wikipedia defines strategy as:
“…a long term plan of action designed to achieve a particular goal, most often “winning.” Strategy is differentiated from tactics or immediate actions with resources at hand by its nature of being extensively premeditated, and often practically rehearsed. Strategies are used to make the problem easier to understand and solve.”
You can boil that down to strategy is about having the best plan. Whenever I hear people talk about not being strategic enough (or I catch myself doing it), three thoughts immediately pop into my head:
- Being strategic is not binary; you don’t wake up one day and say “today I am strategic!” It is a journey and a destination.
- If your goal for being strategic is to be well regarded, to be a leader, and to “win,” remember that people follow leaders that inspire not only by their words but by their actions. Even great strategic thinkers have to get into the tactical muck and implement their grand plans.
- You can control how strategic you are by your own actions. If being strategic is about having the best plan, and by extension the best/smartest/most agile thoughts, you can train your brain to be a step ahead of your competition and your peers. Here are some thoughts on how.
I’ve been fortunate to work with some really bright thinkers so far in my career and picked up a few tips on how to be a more agile thinker. Everyone has their own processing style, for instance I like to digest and think on a topic for awhile before coming up with a plan of action, but you might be a snap thinker who can do all of this on the fly - if so you’re ahead of me! Note that some of these questions overlap in scope.
Ways to be a Strategic Thinker
- If we take the current action, what will be the downstream results to X, Y, Z? How will they likely react? How will we counter-react? You can’t get through a strategy discussion without a chess analogy, so here you go. These questions help you anticipate the moves of your competition, channel, etc, and decide beforehand how you want to react, so you’re not caught flat footed.
- Who and what else are connected to this decision? How will this affect them? I like this question because it forces you to think through the implications of your decisions early. It’s easy to sit back and say “let’s change our distribution model” or “let’s move to SaaS!,” but being able to accurately predict and describe the challenges of plan of action will help guide you to the best choice.
- Ask the Five Why’s; This sounds like a something out of a kung fu movie, but the Five Why’s are real. Five Why’s is a B-school/consulting method that says if you ask “why” at least 5 times you can get to the root of the problem. It’s all about digging deeper. Observe:
“I hate your company.”
“Why?”
“Because I have to wait for tech support for 3 hours to get someone on the phone!”
“Why?”
“Because your product didn’t work right when I plugged it in!”
“Why?”
“Because when I went to training they didn’t tell me I needed to hold the reset button while I plugged it in to load the factory settings!”
“Why?”
“Because your training is a joke, it’s all sales and no technical!”
“Why?”
“I only went because I couldn’t get a sales guy to call me back!”
In this example what appeared to be a product problem may actually be a sales, training, and support problem..
- What external influences will affect me in the future? If your competition introduced a product tomorrow with the same features as yours at half the price, how would you react?
- What internal influences will affect me in the future? If your company downsized and you lost half of your development staff, how would you react? What if you faced mega sales and had to quickly scale up?
- Where is “good enough” okay, and where do we really need to invest to provide an out-of-this world experience? You can’t do everything perfect all of the time.
- If I had unlimited funds, what one product development would move the revenue/profit/customer satisfaction needle more than all others? Which needle is more important to move?
- If I had only one development dollar, where would I put it and why? This is closely related to the question above it.
- Why are we winning today? Why are we losing? You need to understand your current stance if you want to build a solid future plan.
- What do we do better than everyone else? Do you understand your core competency?
- What problem do we need to solve for the customer? If you don’t know this…find out fast because it’s probably different than your assumption.
- What barriers exist to prevent us from winning? Is it better to smash through those barriers, or route around them? Sometimes the only road to winning is to go through a competitor. But it’s 3-5x more difficult/expensive to gain a new customer than to recruit business from existing customers. Is there a way to win business without a head on confrontation?
- What can we do that’s never been done before? I love this question because it’s challenging. It doesn’t just apply to engineering either, you can apply it to Marketing and Sales as well.
What other ways do you use to be a better strategic thinker?
ProductCamp picks up three more Sponsors!
I’m happy to announce that ZIGZAG Marketing, Accept Software, and Ryma Technologies have stepped up to sponsor ProductCamp Austin! The response to our little event has been nothing short of overwhelming. At last count we have over 115 participants registered, 10 sponsors, and over a dozen interesting and relevant sessions being offered by our participants.
Some of the sessions you’ll see at ProductCamp include:
- Startup Product Management: How to Build a Successful PM Practice at a Startup (Paul Young)
- Roundtable Discussion - Global Product Management: Working with Offshore Development and Manufacturing (Paul Young)
- Followup Roundtable - Global Product Management: Can Requirements Be Done Offshore? (Scott Sehlhorst)
- Technology Assessment: Where to put your Development Dollars (John Milburn)
- Feature Prioritization: How do YOU do it? Learn from other’s experiences!(Bjorn Aannestad)
- Priorities and Roadmaps: Guiding the Successful Business (Pat Scherer)
- Navigating the political minefields of product management (Charlie Ray)
- Time management for PMs: Completing projects on time and on budget while staying sane (Charlie Ray)
- What does a Product Manager need to know about intellectual property - BEFORE spending $500/hr with a patent attorney (Don Jarrell)
- Public Relations 101: What It Will Do, What It Won’t Do, and How to Use It to Develop Key Messaging and Build Your Brand (Deborah Maggart/Phil West)
- Career management for product managers - transitioning into and out of product management (Colleen Heubaum)
- UX 101. Creating a framework for delivering consistent - and delightful - user experience. (Ben Phenix)
- Developing a Successful Product Launch Plan (Cathy Liggett)
I’m looking forward to a great day of teaching, learning, and networking. We’ve got more out-of-town guests coming that we had expected, so check the wiki site for hotel information.
Also, that evening, ProductCamp and the AustinPMMForum are co-hosting a happy hour sponsored by Ryma Technologies at Iron Cactus North in the Agave Room. If I know Product Managers, we’re not going to turn down a free drink. That may end up being our most highly attended “session.”
How to Have the Worst Beta Ever
If you run Product Management, especially in a smaller company, you may find yourself running the beta program. This is a tactical activity, and you will be knee deep in beta user qualification, feedback, administration, possibly even support, but you can take positives from a good beta. Or you can fail miserably if you don’t understand that there are different flavors of beta, and different motivations and goals behind each.
One of the biggest issues I have run into with beta is that there are several types of beta. It took me (too) long to figure this out, so hopefully I can shortcut the learning process for you. Some flavors of beta:
- Post-Alpha Beta - This is what most people think about when they say “beta.” A final test to find bugs and make last second tweaks before you roll up for release. Depending on the size of company, sales model, and other factors, you may have “release candidates” that come out of beta, or several iterations of beta code.
- The Sales Beta - Sales is drooling over a feature in the next release and has to “get their customer into the beta” to make the sale.
- The Google Beta - A beta that never ends. Gmail is still beta after how many years…really?
- BINO (Beta in Name Only) - Your development cycle went long, and you don’t really have time for a good beta, and you can’t move the release date. Hope your QA is good!
- Not Ready for Beta - The opposite of BINO, your code isn’t ready but your beta testers are, so you put something in their hands that is better described as Alpha and they freak out.
You never want a BINO or Not Ready for Beta, and the good news is that Product Management controls those dates, or should. The Sales Beta is the worst, because they always promise up and down that their user will offer good feedback and will be a great beta participant - don’t believe them, because they lie! What really ends up happening is that Sales forgot to mention that this product was beta, the user gets the product and then they are both confused or angry that it is not ready for primetime. That is a sure fire recipe for failure.
The Google Beta is interesting because having a product in perpetual beta is convenient. Don’t like that bug? Sorry, it’s beta - see the image at the top left that says “beta” in 8pt light grey font? That might fly for free or ad supported products, but I doubt a paying customer will accept a product in forever beta.
What other kinds of beta have you seen?
Webinar - To Startup or Not to Startup
On Friday at 10-11AM Pacific, John Milburn of Pragmatic Marketing and I will host a webinar on Product Management in a startup. John is a true expert, and has been in the Product Management game for 20 years from companies as big as IBM, down to being the founder of a company in a startup. My experiences come from making the move from a Big Company (Cisco) two years ago, to a small startup, and building the Product Management and Marketing functions from the ground up. This should be an interesting and fun hour, so please join us for the discussion!
If you haven’t seen the original article that we wrote for the Pragmatic Marketer, go give it a read, we will expand on these themes and toss out some ideas about how to succeed in a startup.
Seilevel Sponsors ProductCamp
ProductCamp Austin has hooked another sponsor - Seilevel. Seilevel helps companies write better software requirements. From their website:
Seilevel is a professional services company that creates software requirements documents for Fortune 1000 companies. Leading companies turn to us to identify and delineate their needs because of a proven approach to software requirements that saves you development dollars and maximizes resources. Seilevel gets the requirements right, so our clients get their software right.
We’re thankful to have Seilevel onboard for what will be a great Product Management and Marketing event. In addition, Seilevel is going to propose a session on requirements, and send a representative to take pictures during the event - we’ll post them on Flikr afterwards.
The Failures and Successes of Open Source Product Management
I kicked over a small ant hill last week with my post about the (lack of) Product Management being a fatal flaw to open source software. Both CNet and Linux Today chimed in, and that story incited some really good comments. Some of the commentators were gracious enough to continue their dialogs with me in more depth over email. It’s only fair that I follow on that post with some of the great points they made.
First, there was some confusion between Product Management and Project Management. Product Management is still poorly understood and inconsistently implemented in technology companies, so it’s understandable that lots of open source programmers may never have worked with a good Product Manager. Here’s an email exchange I had with a commentator (who asked to remain anonymous):
Paul: …maybe we’re talking past each other on the definition of project management vs. product management…
Anonymous: …I use them nearly interchangeably since all products result from projects. The problem I have in your posting is your blanket implication that development style makes FOSS management inferior….
…I disagree strongly that project and product mgmt are interchangeable terms. Product management is the discipline of discovering, documenting, and prioritizing user problems, it looks at the market strategically and seeks to understand where the greatest user pain is and (in commercial companies) which problems can be solved with the most profit. Project management is tactical scheduling, resource allocation, etc…
This leads to Point #1: The “Product Management Probem” is not unique or limited to open source projects. This is completely valid. You can easily point at Microsoft or other commercial software companies for examples of products that had poor product management and don’t necessarily solve a pressing need. The Pidgin example happens to offer a teaching opportunity in the FOSS world, showing that no person or model is perfect.
Point #2: Many commenter’s stated (paraphrased): “We don’t need Product Management, that’s for commercial companies; free software already has a method to determine wants and needs across groups of users - it’s called forking!”
Forking is when a developer decides to branch off of a project to create something different, usually withing the same vein and built on top of the work that has occurred to-date. In fact, there is already a fork of Pidgin called Funpidgin that exists just to give users back the features that the Pidgin team “took away.” I would say that forking is a very inefficient way to solve this problem, but a commenter smartly called me out on that point saying that unlike in commercial companies, open source projects are not resource-bound - they can afford to be inefficient.
The main point of the post, beyond even the Product Management topics, is that a FOSS project can have one of two primary goals: either the developers are creating for themselves, or they are creating for others. To create for yourself means that you recognize user input but don’t feel any obligation to take it since you’re building an application for yourself. If the user happens to enjoy it, great. If not - fork and make something you like.
If you’re creating for others, you should be interested in the wants and needs of your target user base. This might mean forgoing a “cool” or technically challenging feature like auto-resizing text boxes. Now that open source software looks, feels, and acts like many commercial packages, users assume that the application was developed with their needs in mind. If the application does not meet their needs, they feel justified in offering feedback. This is where the disconnect comes from: users who assume that an application was developed for them and programmers who believe they are building primarily for themselves. If the programmers are interested in working for a larger user base, a strong product manager could help them fill that gap.
What if when you went to to SourceForge, you saw a badge affixed to the link that told you if this was a for-developers or for-users download?
At least if you understood this bit of information at download time, as a user you wouldn’t bother going to offer feedback to a team that isn’t interested.
Point #3: “FOSS projects air their dirty laundry for the World to see, whereas commercial products get to keep it inside their four walls.”
Yes and no. Yes, open source is out there for everyone to see. Don’t think for a second that just because a product is commercial that the tradeoff decisions those teams make don’t spill onto the Internet. Just look at Microsoft Vista for an example. Or Facebook’s advertising platform.
Point #4: “There is Product Management in open source today! See JBoss, Mozilla, and others!”
This is an important point that I’d like to recognize. There are companies and projects that are contributing PM to FOSS projects.
I’d like to thank everyone who participated in the discussion!