Monthly Archives: November 2008

Vote for us! (once again)

canblogawardsOnce again, we’ve been nominated for an award.

Last time it was for Best UK Project Management blog. Remember that? Given that we’re neither UK based, nor focused on Project Management, we didn’t expect to win.

This time, both the geography and the category fit us well. We are nominated for the Canadian Blog Awards under the heading of Best Professional/Career Blog.

So, we’ll keep it short.

VOTE FOR US!<<– Click here

Vote now. Don’t delay. Really, click that link now and vote.

PM mind trick coming… This is the blog you want to vote for….

Show all those other bloggers that Product Managers support their own. Doesn’t matter if you live in Canada or not, vote for us. We’ll share the glory of winning with all of you. We promise.

Saeed, Alan, Ethan

Working with Sales and Marketing

A common question for Product Managers, is how to work effectively with other teams; in particular, Sales and Marketing.

Over the coming months, I’m going to spend more time on this subject. When Product Management, Marketing and Sales work together effectively, great things can happen. This is what happens in successful startups, but somehow usually gets lost as the company grows and silos and politics sinks in.

Do you have any questions on the topic that you’d like to see answered on the blog? Leave a comment and let me know and I’ll try to answer in the weeks ahead.

Saeed

Trialware in a virtual world

My Windows world is totally virtual. My company Eigenworks runs mostly Macs, but we have VMWare Fusion Virtual Machines for various purposes. Just the other day, for instance, I needed to do some detailed pipeline analysis for a Win/Loss client, and needed to fire up a Windows-only app.

I now keep a few VMs on my machine for different purposes. I have one small, bare-bones VM, one VM with essential apps installed, and one huge VM that has a lot of stuff installed … I don’t restrict what I install there. Then I keep “virgin” copies of the VMs on a backup drive, and if something goes wrong, I simply blow away the wonky VM and restore it to its virgin state.

Something about having Windows run in a “window” is very satisfying. I sometimes wish I could virtualize other things in my life, like some of the people. But I digress.

What about licensing? Vendors who write software that is commonly run in virtual machines have a tough challenge, and there are various solutions for that. (A decent article about the issue is here.)

But my question is more about trialware for single end-users. Once upon a time I managed a product line (which we created here, then rebranded here, until it was acquired), that ran mostly on developer workstations on Windows. We had 30-day trial licenses, which could be managed easily because we were able to place a marker on the computer to disallow a user from reinstalling a trial.

That was in the days of physical machines running Windows. What happens now when anyone can simply clone a VM and start again?

Are you dealing with this problem? What do you do about it? Does it really matter, since most individual users don’t know what a VM is yet? Share your experience in the comments below.

Alan

The Agile Disease…

Having written a fair bit recently about Agile/Scrum, I found the following post provided an interesting perspective.

The Agile Disease by Luke Halliwell

I don’t agree with everything the Luke wrote, but a lot of his points make sense.

A lot of the benefit of Scrum is handled if people simply use common sense with whatever process they use. I’m happy to say that at my current company, we just put out a major release of our product, included a lot new functionality and platform support, as well as renamed, rebranded and repackaged how we will sell the product, all in a 4 1/2 month development and test cycle, and all WITHOUT using Agile.

That team will be moving to Scrum very soon (corporate mandate), and I’m interested in seeing what, if any, efficiencies they’ll gain. I think the best way to make that team more effective is give them more developers. :-) We have a big backlog!

The one point that Luke made that particularly caught my eye — and I’m surprised I didn’t realize it before is the following:

“Individuals and interactions over processes and tools” I couldn’t agree more with, but strangely, Agile is all about following processes and rarely mentions that having top people is the best thing you can ever do for a project (you could say your hiring process is more important than your development process!).

The irony of the first element of the Agile Manifesto and the fact that Scrum imposes quite a bit of process on people — Scrum Master, Product Owner, backlog management, daily standup etc. — should be noted.

Saeed

A 5th element for the Agile Manifesto

Robert Martin gave a keynote at the Agile 2008 conference. Entitled Quintessence, he talked about adding a 5th element to the Agile Manifesto. His suggestion was:

Craftsmanship over Crap

After discussion and thought, he later proposed a refined version:

Craftsmanship over Execution

This is meant to focus developers on writing good code vs. simply writing code that works. Both craftsmanship and execution are good things, but taking care to write good code is viewed as more important.

The attitude is described in the Principles behind the Agile Manifesto, but is not explicitly listed as one of the elements of the Manifesto itself.

Continuous attention to technical excellence and good design enhances agility.

But few people seem to think about those principles explicitly. The focus of many agilists is specifically on the 4 elements of the Manifesto itself.

But, is this really a principle that needs to be enshrined in the Manifesto? Shouldn’t everyone (ideally) take care of the details and be diligent in their jobs?

In my opinion, looking at the the Agile Manifesto:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

I don’t think it’s sufficient to be added to the list. Don’t get me wrong, I agree with the call for people to do good work, but to me that should be a given. The beauty of the manifesto is that it is concise. Each element is clearly distinct from the others and espouses a different aspect for the profession: people, code, customers and agility.

What’s missing from the Manifesto?
But there is something that is missing from the Manifesto. Most software is written for business purposes. It could be an internal IT team or an ISV, or part of some other technical product that will be brought to market. This context needs to be in the mind of development and QA teams as they produce and test code. And as they make decisions on what to do and when, they need to decide if it is important for the business or not. And if they don’t know whether something is important, they need to know enough to ask.

I propose the following as the 5th element of the Agile Manifesto:

Business alignment over engineering efficiency

Why? Because as trade-offs are made, as test cases are created, and bugs and issues are prioritized, the overall business context must be kept in mind.

No set of requirements will provide every constraint that needs to be taken into account. No set of user stories will be perfect, regardless of how intimate the Product Owner is with customer and market needs. No individual can tell the testers the best combination of tests that need to be run.

The focus of Agile is on “individuals and interactions”, and those individuals need to be empowered to make appropriate decisions. But, without the proper business context, they will not be able to optimize what they do.

Have you ever had software that couldn’t install properly? Or had licensing problems? Or found certain design decisions prevented the product from easily being OEMed by partners? Or had APIs in the product that were only usable by the developers who wrote those APIs? Or had user interfaces (radio buttons, check boxes, drop downs etc.) that functioned more like a developer’s logic path than a user’s intended workflow? These are are all cases where the business context was not kept in mind.

I once saw the following happen with a software product. A customer had purchased the product and licensed some modules. When they installed the product, the license keys for at least one module didn’t work. The module’s functionality couldn’t be enabled. The Support team identified it as a bug in the licensing functionality and escalated it to Product Management.

The PM went to the head of QA to find out more about the problem. The conversation went something like this:

PM: Hey, just wanted to confirm whether this bug with licensing is really a bug?

QA: Yes it’s a bug.

PM: Then it’s a regression right, because I know the licensing worked in the previous release.

QA: Yes, it’s a regression.

PM: So, how did we miss this? Who tested the licensing?

QA: [Looking at the PM more intently] No one tested licensing.

PM: Uhhh…what do you mean by “No one tested licensing.”

QA: Licensing wasn’t tested because there were no licensing changes between releases. We have to prioritize the work we do. We can’t test everything. What do you expect? Zero bugs? That’s never going to happen.

PM: Agreed, you can’t test everything. And I don’t expect zero bugs? What do I expect is zero surprises and licensing that actually works. Licensing is how we make money. It has to work or there is no business.

QA: Look, there will be a patch out tomorrow. And as I said, we can’t test everything. We didn’t test licensing. And I’ll tell you, if my boss was here right now, he’d support me in my decision.

PM: I have my doubts about that.

It turned out (thankfully) that the QA Manager’s boss didn’t agree with him. But, the QA head was not a junior guy. He’d worked in software for about 10 years. Yet he didn’t understand how important licensing was to the business. From his perspective, it was no different than any other “feature”.

I’ve seen this kind of thing many times from Engineering teams. It’s not just applicable to licensing. For example, when they promote the creation of SDKs and APIs when end-user functionality is what is required, or advocate for “rearchitecture” or “refactoring of code”, when neither provides any clear business benefit.

This kind of thinking has to be rooted out of the culture of software development. Other groups such as sales and marketing, albeit because they are close to the business side of things, better understand how to prioritize business needs. Software development needs to line itself up as well

We want efficient engineering teams. They should not be wasting cycles on non-productive work or work that has little value. But, that drive towards efficiency, velocity and productivity cannot be blind to the priorities and needs of the business. Those business priorities must be incorporated into the day-to-day decision making that takes place in a product development cycle.

When all teams in the company from Product Management, Sales, Marketing, Operations AND Engineering understand and embody the needs of the business, as often happens in the tightly-knit teams of a startup, the business can truly deliver on it’s promise and potential.

Do you agree/disagree? Would love to hear from you.

Saeed

US Election wrap up (I promise, last post)

Well the results are in. I have to say that Obama’s acceptance speech was very inspiring. He went well beyond “good positioning”, and while listening I felt humbled about my posts earlier that dared to critique his positioning.

Here’s why:

Part 1: Inspiration. So often as a marketer, product manager, consultant, or worker of any sort, it feels as though we’re putting the best lipstick we can on the product we’re working on. But how inspiring are we? How inspired are we? What is the last product you worked on that actually inspired you?

What Obama did on Tuesday night was to inspire people; it was almost non-partisan. I heard so many people saying that they woke up the next day feeling brighter, more optimistic. Of course reality will be interesting to track, and the road ahead is not an easy one, but I got the feeling that this guy has what it takes to really lead.

Part 2: The “new rules”: Good positioning is, of course, extremely important. Without your positioning straight, it’s hard to do anything well. But Obama’s campaign went well beyond good positioning, and leveraged some very powerful marketing tools. Seth Godin’s blog article on election day was the best explanation I’ve read.

My original post referred mostly to the debates, which I still believe were poorly executed on both sides. Obama’s oratory, though, is second to none.

Let’s hope his leadership can measure up!

On Election Day

As the United States selects its new leader, those of us unable to vote are also holding our breath, waiting for the outcome. What does this have to do with Product Management?  My answer: (i) candidate positioning is, after all, positioning, and I wrote earlier about how I would write positioning for each candidate, and (ii) the whole world cares about the outcome. Even Canada.

On the first topic (positioning), a recent Obama speech sounds like someone in the DNC is reading this blog! The speech was given last week, and while I won’t do a blow by blow, the similarities are astonishing. Read my recommended outline (here) and Obama’s speech (here). Bravo Obama! Actually I think his acceptance speech at the DNC followed a similar outline, which I call the Roller Coaster. I tell you – if you’re doing product positioning – take a look at that outline! I’ve used a lot of positioning techniques, but always come back to the roller coaster. I’ll write more about that in a future post.

And yes, the whole world cares about the outcome of the American election. In some ways those outside the US think they should have some kind of say, because America holds such sway in the rest of the world. To satisfy their desire to do something, here’s a site that is aggregating votes in the Presidential election according to country (presumably based on an IP address look-up. According to the 745,000 votes recorded by the time of writing, 89% of their voters around the world prefer Obama. Country by country, only Macedonia prefers McCain, apparently due to a recent senate resolution in which Obama took sides with Greece in a dispute with Macedonia.

If the site linked above is representative of the opinions of internet-connected people around the world, isn’t it remarkable that nearly 90% of that sample of the world favors one candidate over the other? Surely this cannot much to do with the details of Obama’s platform; even American’s couldn’t say much about those details. No, it must be more of a comment about the overall evaluation of the Bush administration by “clickers” around the world. I’m not sure what that should count for, but if I were running for office, I think I’d pay attention to the sentiment. Having the world against America’s next choice of president can’t be a good thing for anyone. On the other hand, if the world sees a more friendly, cooperative president, it would seem to bode well.

Good luck America. Get out and vote!

Alan

ProductCamp Toronto – A Success

Today, we held the first ProductCamp Toronto downtown at the Ted Rogers School of Business.

About 100 people showed up in the morning to listen and participate. Some of them came from as far away as Boston, New York and Philly.  If you couldn’t attend or want more information, here are a few links.

The list of sessions can be found here: http://pct.wik.is

Some pictures from the day are up on Flickr: Here and here. There’s even a few pictures of me during my talk on Defining a Product Management Manifesto.  You may also find some pictures of Alan giving a talk on Win/Loss Analysis.

Here are a few pics from today demonstrating how to catch a basketball. :-)

A number of Twitter users left some tweets on the day. Search for #pct1.

And of course, the Product Camp Toronto wiki is here.

Best line of the day — at least that I heard: “Product Management should suck the air from everything around it!

There’s already talk about a second ProductCamp Toronto sometime in the Spring, so stay tuned.

Thanks to all those who help organize and sponsor the event, as well as, of course, those who took the time out today to attend.

Saeed