Month: October 2007
So, a couple of weeks back, when the CrankyPM’s blog came back from a brief hiatus, I wrote a bit of a welcome back post. In it, I mused that, had the CPM been promoted or started up her own gig, it would have been nice to see that blog come back as the CrankyCEO.
Now, sometimes I do strange things like look up the whois info on domains of interest. So tonight, for no good reason, I decided to look up the whois info of crankyceo.com? While I was not surprised to see it had been registered, I was surprised to see that it was registered YESTERDAY, October 9, 2007! Gee, wonder if John Crespi reads this blog?
So, that got me thinking, was it really my idea? A quick search for “crankyceo.com” on Google, and voila!
Only 2 hits out of Google’s 8 bazillion page Web index and both from our blog! Yes, absolutely my idea! (inspired by CrankyPM of course)
So John Crespi of Richmond Hill Ontario, a couple of suggestions:
1. When you put up your site, I’d certainly appreciate being publicly credited as the inspiration for the domain name.
2. If you make money from the site, please don’t hesitate to send me a small royalty payment. A standard and customary 10% of gross revenues will suffice.
3. When you register your domain, you may want to check the option for hiding your personal registration details.You never know who is going to conduct a whois on your domain.
As a Product Manager, you are required to deal with all parts of the company, from marketing to development to finance to operations to the executive team; you need to be able to work with all of them. Furthermore, you are often an agent of change in the organization. You need to sift through massive amounts of information, find the relevant bits, assemble them, synthesize, and make an argument for changes. In fact, if you’re not changing something at your company today, just what are you doing?
It’s worthwhile, then, to think a little bit about change and the ways that different people handle change. A lot has been written on this topic and I do not pretend to offer an exhaustive or even a properly distilled treatment on it. But I do have some suggestions. This whole issue came up for me tonight in a totally unrelated context, but one where the issue was just so clearly visible, almost a microcosm of situations I’ve faced dozens of times in work and social environments.
A little story then.
When I lived in the SF bay area, I used to attend an East/West meditation evening at the Mercy Center in Burlingame. Normally I would go for Sushi afterwards, and if you get the chance, you must try Sakae on Park Road in Burlingame just across from the Apple Store. And after a Zen meditation session, one should take in a little sushi. But I digress.
Tonight as I am visiting the bay area on vacation, I attended another meditation session. After the meditation, the teacher, Father Greg Mayers SJ, introduced a new aid to meditation that he will be using at the upcoming Zen Sesshin in November. The aid was called a kyosaku, a finely crafted wooden stick that is used in Zen meditation. One of the attendants walks around, and when the meditating person invites the kyosaku, the attendant smacks the meditator on specific pressure points between the shoulder and the neck on the upper back. Each side gets two smacks. The smacks are not painful. Rather, because of the construction of the kyosaku, the technique used, and the pressure points used, the smacks help to clarify the mind and also help release certain muscles that can become sore and tight during long sitting meditation sesshins.
Why is this relevant? Well, after the teacher had his student demonstrate the technique on him, he began to describe the purpose of it. The reaction from the room of meditators was quite fascinating:
- One woman began by saying that she was very offended by the presence of the stick in the peaceful meditation room. It reminded her of the stick that nuns used to use to punish catholic school kids. She said that she would not attend the retreat if that stick was to be used.
- Another chimed in that she agreed. She said that the symbol of a person hitting another, regardless of whether it was helpful or hurtful, the symbol itself was simply intolerable.
- The teacher welcomed the comments. He reaffirmed though that the kyosaku was going to be used at the Zen Sesshin, not in the regular meditations, but it would be used on that weekend. It was a liberating aid to meditation, and that it would only be offered to those who requested it, and that no harm would come to anyone.
- One person reflected on her experience of receiving the kyosaku unexpectedly during a Sesshin in Toronto. She said that although she was unaware of what she was receiving, it was a tremendously clarifying aid to her meditation, and that she was glad to have received it. She said that there was no pain involved, on the contrary, it relieved some muscle tension.
- Others suggested that perhaps another method should be used, such as gentle touch.
- Later in the discussion, others chimed in.
- One person said that he had been coming to these sessions for several years and had never heard of the kyosaku. He did not like the idea of changing anything.
- Another said that he had been on a Zen path for five years, had never heard of the kyosaku, but after the explanation, he was opened to the idea. Initially he might have thought it negative, but was now open to it.
I was quite amazed by all of these reactions, and my own reaction. Initially I was very intrigued by this instrument and I found the idea of such a clarifying aid to be quite exciting. As I saw it demonstrated, I was even more intrigued. I was hoping they would call for volunteers right there!
When the discussion got underway, I found myself quite stirred by it. I felt angry, but was probably just quite upset that such a promising aid was dismissed without understanding. I perceived that fear and people with stuck, fixed ideas, were trying to shut down something that could be quite beneficial. I expressed this to the group. I also suggested that these feelings of fear could be seeds of further meditation, and that perhaps the very fear they were experiencing was itself a teacher for them. They weren’t buying it, but I did hear some positive feedback about that idea after the discussion.
Why have I spent so much time describing this situation? And how is this relevant to you as a product manager? Different people have different attitudes to change. You need to learn how to read peoples’ styles and do your best to adapt to their style. If you can’t adapt, you won’t get very far with those people. If those people hold crucial power or are responsible for crucial activities, you’ll be left with big holes in any plan you hatch.
How can you adapt? I have certainly hit my own pitfalls and have failed to adapt in many situations. In some situations I’ve managed to work with others with very different styles. Here are some things I’ve learned, and I’m interested to hear from you about your own experiences, especially links to articles that would be helpful. We will repost them in our article list.
OK, so here are my ideas:
- Relationships are important. If you develop relationships with people, they will have a larger context with you, and you will have the ability to approach them even when you are blocked on a particular issue. If you are only dealing with a person with a very different style and you have no relationship, you’re going to have a very hard time getting anywhere. This means that you need to take time to get to know people and really care about them. You can’t fake this, it has to be real. I have worked with people very different than me but have also worked hard to find the things about them that makes them effective and even likable, and try to notice when that comes through. I try to tell them about it and share my positive thoughts about them, with them.
- Figure out what kind of information people will accept as decision-making criteria. Some people need data, others need personal connection, others need to talk things out. Whatever they need, you need to try to furnish it. If a discussion is what a person needs, spend time with them, preferably over a meal. If they like data, provide the data. A lot of people need to understand how the change will affect them, particularly if their own position will change or be threatened by something you want to implement. Work with them to find a solution, or flag the issue for HR and upper management. Ask HR to work with you on the issue.
- Focus on defining the problem first, and gaining agreement on the problem to be solved. This is 80% of the battle. If people agree with you on the problem definition, on what is wrong with the current state of affairs, they are much more likely to be open to solving it. They also need to believe that the problem you describe is relevant and significant; it can’t just exist, because there are a lot of problems and we can only fix some of them. They need to know why the problem matters to the company and to them personally.
Some people need to be involved in problem definition, and you may need to redefine the problem if someone provides information that might change the problem definition. In any case, a robust, believable, complete, and true problem statement needs to be agreed on before any change will be made.
- Once the problem is defined, try to get people involved in creating their part of the solution. This is tricky because some people aren’t able to generate solutions, and some simply don’t have time or are not interested. These people need to be provided with a menu of options or even a very specific set of directions. Ask the question “how independent, how competent, and how involved is this person?” The more independent, competent, and involved, the more they need to have a hand in the solution design. In fact if you are a generalist product manager, or even someone with limited time (!), you NEED THEM to create the solution. Try to get buy-in from their management for them to help you solve the problem. For this, their management will need to buy in to the problem statement.
- Get management support. Sell management on the problem and the need for a solution. Share with them the degree to which you need or want help in designing the solution, and gain the commitment of their resources.
For some of this thinking, I am indebted to Interaction Associates, a collaboration consulting and training company in Boston and San Francisco. They have models for creating a “path to action” that describe the problem, vision, constraints, and solution approaches. I recommend checking out their classes on collaboration and facilitation; they’ve really helped me. They have a solution design model that I can’t find on the web and my copy can’t be redistributed. But really, check them out.
Again, I would love to hear from you about your ideas here and relevant articles.
Pretty much everyone agrees that resilience is good, especially in software. When one of a million external dependencies fails you don’t want your software falling over like a poorly designed tower.
So how could resilience possibly be bad? Resilience goes bad when an application gracefully – and silently – handles an error even though the error was really, really bad. (One of these examples came up at work today but I won’t say which one). And apologies to Jeff Lash.
Good Resilience: Your application is flexible enough to let users install it on machines that don’t exactly meet the minimum resource requirements. After all, let’s not be picky.
Bad Resilience: Your application is willing to let users install it on a machine that will run so poorly that it will make the application look bad. Users might say “Does it really need two gigabytes of memory? Really?” but if the application is using some sort of SQL-based database storage, yeah, it probably does. And when it runs like a dog? It’s your company’s fault.
Good Resilience: Your application doesn’t scream and crash when a file it expects to find isn’t present. Yay for not crashing.
Bad Resilience: When an expected file is missing, your application merrily continues along and provides the user with the wrong results. Like the previous example, the application is a bit too resilient.
Good Resilience: The application lets any user run it.
Bad Resilience: The application doesn’t check to see if the user has sufficient privilege to carry out the operation and indicates that something is missing when, in fact, it’s only missing because the user can’t access it. Windows apps may not care about this much, but for those “UNIX-Enterprise” apps, this can be a real headache.
Most of the time requirements capture what happens when all the stars align and everything works correctly. But spend some time with your pre- or post-sales field staff and it quickly becomes apparent that requirements also have to describe what should happen in bad situations that can be reliably predicted (or, more realistically, how the next version should handle the situations that have the field people pulling their hair out).
I wasn’t fortunate enough to be in Seattle or New York today, the initial two cities selected for the launch of the iTunes / Starbucks wifi store. The news is that the user experience is smooth, even if there were a few initial glitches along with one usability complaint reported by this reviewer. Frankly I am not surprised that there were a few glitches with this one. The baristas pull a mean espresso, but I doubt the T-Mobile gear has on-site expertise.
I think this is a brilliant move for both Starbucks and Apple. Starbucks has been aspiring for a few years now to become a third place, somewhere we can all just go and hang out between home and work. It has wifi, unlimited use of its couches, comfy chairs, working desks, and a supply of coffee and sweets limited only by the balance on one of your plastic cards.
And of course Starbucks is monetizing this third place. Now it is looking to expand its access to a market segment totally distinct from coffee and sweets: music distribution. But why create another HMV or Virgin Record store? Instead, it is serving up iTunes Store for free through its T-Mobile wifi connections. I need to dig for some info on the relative monetary value projected for music vs. coffee. Please send me a note if you have any info or links to such info.
I still get noticed when I pull out my iPhone and take a picture, check my mail, or just call someone. But today I was wishing that Apple and Starbucks had chosen the San Francisco bay area to launch its partnership, and I would have been there to write up the experience. It wasn’t to be.
Instead, I was in Monterey today, and went into Starbucks to tease the baristas for not being among the launch stores. As they were making my espresso macchiato, I discovered yet another co-marketing action: The Digital Release!
Here’s the concept: Starbucks promotes a shiny card looking like a CD cover, which is actually a coupon you can purchase at Starbucks to allow you to go home (or to your laptop in the store) and redeem the coupon for an album at the iTunes Store. Here are a couple of pictures of the cards I bought.
Not having my laptop with me, and not being able to use the iTunes store on my iPhone, I waited until I got back to Belmont, and typed in the code for KT Tungstall, Drastic Fantastic. I’m listening to Hopeless now as I type.
Will this method of distribution work? I’m skeptical. What is the benefit for the buyer of these shiny little cards? I had to buy one. OK, I bought two. It’s a business expense for me to check out the workflow, test out the concept, and write about it. Not sure my partners would agree, but after all I only spent $25.
But here’s the thing. I don’t get anything extra by buying this card versus just buying the Deluxe version of the same album on iTunes. So really the only thing this little card does is to serve as an advertisement for this particular album, and perhaps an ad for purchasing digital music. But if I want the next album they advertise, I likely won’t buy the card. I could lose the card before I got to my laptop.
Maybe I am missing the point? Maybe Starbucks gets a larger cut for the shiny cards because it can say that it legitimately influenced the purchase. Or perhaps it allows Starbucks to advertise more “Starbucky music” with less cost of materials. But these all seem like benefits to the seller, not to the buyer.
I don’t think there is much future for the shiny little cards. I will of course keep mine in a safe place to show my kids years from now, alongside the 8 tracks, cassette tapes, and vinyl records ,and even CDs and DVDs that they will laugh at in a few years. Perhaps I have in my possession one of the rarest forms of music distribution ever! Seriously, I don’t think it will last. But I’ll be watching, and I hope you’ll let me know if you disagree.
But iTunes Store over wifi? That will be a huge win. If only I could get myself to a city where they offer it this month.
As part of the second Pragamatic Marketing blogfest, I’m responding to Steve Johnson’s post: “Everyone needs to know what we do here“.
In it, Steve writes about the need for domain knowledge for technology workers, particularly in regards to the business they are in and the needs of their market. Whether talking about engineers, marketers, sales people or product managers, everyone needs to understand the company’s strategic objectives as well as some aspect of market dynamics.
In this case, I can’t really argue too much with Steve. If key people in a company don’t have domain knowledge, then the question “Why not?” must be answered. Do your competitors have domain knowledge? Most likely, especially if they are leading you in the market. How can anyone run any kind of successful business without domain knowledge?
For technology companies, the questions to consider revolve around defining exactly what “domain knowledge” is, and how best to acquire and maintain it.
Domain knowledge, particularly in B2B technology companies, can be quite complex. Not only do Product Managers need to understand the overall market, but also market specifics that vary from geography to geography. They need to understand overall trends in the market, as well as technology and economic trends that could impact product performance. Then come the questions related to competitors — who are they, what are their strengths/weaknesses, and where are they heading? Finally, Product Managers need to understand their target customers in detail — what they do, what they find valuable, how they currently use your product (or one of your competitors), and why they would value yours.
All of these areas of knowledge constitute domain knowledge. The reality is, very few individuals can have a full understanding of all of this information. I believe there is a myth that the lone Product Manager can collect, analyse, understand and then react to all of this information. The reality is that technology companies should look at the Product Management function as opposed to the individual Product Manager, as the locus of this knowledge.
Clearly other teams in the company also have domain knowledge, but Product Management needs to collect it and put it all together to make a coherent picture out of it. To do that well, it can’t be the responsibility of a single individual. Companies should be thinking about Product Management teams for each of their products or product families.
Some companies seem to succeed in spite of themselves. You’ve all heard of (or maybe even worked for) at least one of these kinds of companies. They had an innovation that lead to a successful product, but couldn’t repeat that success. Why not? One of the principal reasons is lack of sufficient domain knowledge to make the leap to a second successful product.
Remember Delrina Corp? The makers of WinFax? Back in the early 1990s, WinFax was the clear market leader for faxing on Windows operating systems. Everything in the company was focused on the Windows operating system.
I was a technical writer at the time, and was hired to join the “small but growing” Macintosh team at Delrina. The goal was, as I was told, to build out a whole product line of Macintosh products, with the first product being fax software. And who knew fax software better than Delrina, the people who invented it?
At the time, the core Macintosh development team consisted of three people: the lead (and sole) developer (Don), the QA engineer (Mike) and me (the tech writer).
During the development cycle of the first version of Delrina’s Macintosh fax software, a number of things happened that made me wonder if I’d made a good choice coming to Delrina.
Given that the three of us (Don, Mike and I) were virtually the only people in the entire company who had actually used a Macintosh, most people there only experienced the product through the documentation that I was writing (on a Windows PC using Ventura Publisher nonetheless — not my choice!).
On the Macintosh, the software worked by setting the fax-driver as the target for print jobs. This was done via the Chooser in the Macintosh environment.
At one cross-team meeting to review the development and documentation status, someone, I don’t recall who, asked:
“What are these Chooser and Finder things? Who named them that? Can we change them?”
I kid you not. I couldn’t make that up. Almost immediately Don looked at the person and stated, almost robotically:
“No we can’t change them or rename them. They are fundamental to the operation of the Macintosh.”
I gathered that this was not the first time he had uttered that line.
Later on, the issue of the product name came to light. At another cross-team meeting, it was announced that the naming committee had decided on a name for the product, and all software, documentation, marketing materials etc. should use the name. The name was….hold your breath: WinFax Mac.
Now, if you recall back to the early 1990s, it was the height of the Macintosh vs. Windows fight. Users in the Macintosh community were pretty vocal about their disdain for Windows.
Mike and I looked at each other and waited for Don to say something. Don made an attempt to hide his frustration and then tried to calmly explain why the prefix “Win” as in WinFax was not an acceptable name for a Macintosh product.
The Product Manager would have none of it. He explained the enormous brand equity “WinFax” had, and how strongly attached the name “WinFax” was to fax software and that the plan was to leverage it in this new foray in the Macintosh market. Mike also tried to explain the issues with using “Win” in the name of a Macintosh product and was also shut-down.
A couple of months later, at yet another cross-team meeting, the PM announced that feedback had been received from a large number of beta customers indicating their dislike of the product name, and thus a new name would be found without the prefix “Win” in it. Mike, Don and I looked at each other and rolled our eyes.
Once the project was complete, I decided to leave the company and find employment elsewhere. Even back then, early in my career, I could see the dark days ahead if I stayed at Delrina. I found work at a startup, but continued to track Delrina and their Macintosh product line. A few months later, I saw a review of the product in a computer magazine. The review was OK, but the documentation got a 4 out of 5! I still have a copy of that manual.
As it turned out, the fax product was Delrina’s first and last Macintosh product. Aside from Delrina’s lack of knowledge about the Macintosh computer and user community, they also didn’t understand the dynamics of the Macintosh fax market. Delrina had succeeded in the Windows market by being first to market with an innovative product, and then controlling the channels by signing OEM deals with virtually every PC fax hardware manufacturer. In short, virtually every PC faxmodem that shipped at the time came bundled with a copy of WinFax Lite.
The same strategy had already been executed by other Macintosh fax software manufacturers. So when Delrina entered the Macintosh market, it not only was a late entrant, but the channels were all tied up by competitors. Their strategy, leveraging their Windows dominance to enter the Macintosh market was completely useless. And why? Quite simply because they had no real domain knowledge or true understanding of the market they were entering. Decisions made in a vacuum always look pretty good at the time.