ProductMarketing.com

Software design and making movies

We've often compared the making of products to the making of movies. Both need a business producer (ie., product manager) and an artistic director (ie., product architect or designer). Scott Sehlhorst explores this idea further:

"Alan Cooper presents the analogy that software development is like making movies in his book The Inmates are Running the Asylum. Cooper is presenting the analogy in the context of validating the business case for investing in interaction design. Cooper points out that they've been making movies for a lot longer than we've been making software, and he's exactly right that there is something to learn from the film industry."

Read the full post at Software design and making movies.

CMMI Levels explained

The levels of CMMI came up in a conversation this week. The Software Engineering Institute (SEI) at Carnegie Mellon created the CMM model for software engineering in the late 80's and early 90's. In an effort to consolidate multiple CMM models for different process areas, the SEI team created the Capability Maturity Model Integration (CMMI) in 2002. Read CMMI Levels explained to understand what each level represents.

Reconciling Maintenance And New Releases

One challenge facing a Product Manager is how to balance limited Development resources between the need for maintenance work on the one hand and for new capabilities on the other. Devoting too many resources to one or the other can cause your product to be out of whack and lose ground to competitors who do a better job of mastering that balance.

With limited resources, it is always a struggle to determine what portion to devote to maintenance over new features. It's a little like trying to fight a two-front war: each front draws precious attention and time, and requires careful consideration of priorities. Too much spent on one front may cause you to lose on the other. And as the need for maintenance grows as your customer base grows, your more mature product is probably facing stiffer competition as its market matures and moves towards commoditization. All the while, you can't afford to neglect your base of existing customers.

Read Reconciling Maintenance And New Releases for a discussion of what you need to consider as you continually strike a balance between development on maintenance releases and on new feature releases.

the value-add of product management

Bob C writes,

As I've grown up/older, I've come to acknowledge where my skills and passions lay, and one area of endeavor that just plain doesn't grab me is the deep-dive technical voodoo discussion.

I swear I can't be alone when I say that after a few minutes, all I hear is barking noises. I know they're saying important things that matter, but for the life of me, it comes across as an impenetrable fog of jargon and logic.

Realizing this, and realizing that I wasn't going to bring world-class C and Java coding skills to the table, I came to understand I needed to bring something else that would add value to the endeavor of creating software products & solutions.

So what I do is I try to complement the technical smarts of my resident geniuses with an alternative world-view that employs equal parts lateral thinking and heuristics to get them to think about not just the technology, but the impact of the technology on real people (that is to say, customers). I try to be an advocate for the user, for the market, and to bring that perspective in-house. Since customers think differently than developers, this is a worthy skill, and a valuable one.

Read the rest of his post on working with smart technical people.

On software testing

Testing can be automated. If your testing people need some resources, LogiGear offers these software testing templates, articles, white papers. Software testing templates, articles, white papers and more.

Cooper: Myths and measurements

Steve Calde at Cooper writes:

There's a dirty little secret that nobody in the design community wants you to know: it's actually possible to build and ship a software product... without designing it first! There. I said it. Now my time is short; even as I type, assassins with square-toed shoes and goatees are stalking my whereabouts.

But just because you can construct software products without designing them first, why on earth would anybody want to?

Read Evaluating the ROI of design.

Setting priorities

Joel Spolsky writes in Set Your Priorities: "If you ever find yourself implementing a feature simply because it has been promised to a customer, you're drifting over to the land of consultingware and custom development, which is a fine world to operate in if that's what you like, but it just doesn't have the profit potential of off-the-shelf commercial software."

What did we learn from Star Trek II? "The needs of the many outweigh the needs of the few or the one." And given that development is typically 20-30% of the corporate expenditure, it follows that custom work should be billed at 400-500% of its cost, not offered at a discount to win a deal.

Read Joel's full article for some easy tips on prioritizing a product or a release.

Keep the sharp edges!

Creating Passionate Users has some interesting thoughts on teams and greatness.

'Great software isn't created by committee.' That quote came from James Gosling, at the developer 'fireside chat' at the last JavaOne. And from Applied Minds tech wizard Bran Ferren, 'Art isn't the product of a team.' Is this true?

First, I don't believe James was necessarily talking about the functionality and code when he said 'great software'. Clearly, teams of great programmers can produce great code. I think he means the kind of breakthrough apps that people can become passionate about, and I also think it's less about the programming and more about the design and spec.

Read more in Keep the sharp edges.

Joel on Software - The Project Aardvark Spec

Product managers and product architects may find this a helpful read.

Joel on Software - The Project Aardvark Spec: "As the final version of Copilot.com (what this spec calls "Aardvark") went into production in early August, 2005, this spec is now of historical interest only. I'm making it available as a part of Joel on Software because many people have asked to see some samples of the kinds of specs we write at Fog Creek."

In a later post, Joel adds

“As I worked through the screens that would be needed to allow either party to initiate the process, I realized that Aardvark would be just as useful, and radically simpler, if the helper was required to start the whole process. Making this change in the spec took an hour or two. If we had made this change in code, it would have added weeks to the schedule. I can’t tell you how strongly I believe in Big Design Up Front, which the proponents of Extreme Programming consider anathema. I have consistently saved time and made better products by using BDUF and I’m proud to use it, no matter what the XP fanatics claim. They’re just wrong on this point and I can’t be any clearer than that.”

Working The Plan Using A Plan That Works

The reason Development's planning efforts are so important is that the rest of the company depends upon the success of such planning in order to plan their own work. Functions such as QA and Documentation (if they are separate from Development), Training, Marketing, Sales, Hosting and Production, and Customer Support all need solid assumptions upon which to build their plans. And this is where the Product Manager gets involved.

Without Development's ability to pin down dates and expected results, Product Management can't build reliable plans for product releases, and the entire momentum of your product is affected. So whether a Product Manager wants to or not, he or she must be involved in the planning of Development work.

Read on for ideas on how you as the Product Manager can help get your Development organization to the point where it has clear, useful, and reliable plans.

Read more in Working The Plan Using A Plan That Works.

Pushed And Pulled: Development vs Production

Companies, in the drive to produce new capabilities in their software product and roll them out to the market, run into conflicting priorities. One priority is to keep Development producing new features, where the key is meeting announced dates and moving on to work on the next version. The other priority is for Production to move customers up to the newest software, where the priority has to be doing it at the right time, and doing it right.

Read more for a discussion of how these two priorities push and pull you in two different directions and how to handle them.

Joel on Software - Things You Should Never Do, Part I

I've gotten a couple of emails from folks lamenting that their developers are pushing for a complete rewrite. Before you and your company make a commitment to such a project, read Joel on Software - Things You Should Never Do, Part I: "They made the single worst strategic mistake that any software company can make: They decided to rewrite the code from scratch."

Meeting Promised Development Dates

If you have worked in or with the software industry at all, you have lived through some dramatic delays in product development. For instance, Product Guernsey, originally announced last year, was due in January. It's now the beginning of June, and it's announced that the product, now called Providence, won't be out until September. Or your last major release was supposed to take nine months. A year later, it won't be out for another nine, so technically the team has worked for a year but it's twelve months late.

Sound familiar? Read more in Meeting Promised Development Dates.

Non-Recurring Engineering

Many companies accept "one-off" requests in order to close a deal or to appease a big customer, while knowing that custom work is usually not good business. Some managers defines their professional services role as doing custom work. But when does custom work make sense for a vendor? And how does non-recurring engineering impact the rest of the organization? Daniel Shefer explores these challenges in Non-Recurring Engineering.

Qui propono?

One of the most complicated and often vexed relationships in the tech business is the one between product managers and engineers. If you ask a product manager what they do, they'll often say something along the lines of 'I [lead, guide, direct, oversee] product development' or 'I come up with ideas for products'. A really good one will often put it more like, 'I'm a hub for input into the product from all the functional areas, including marketing, sales, and customer service -- then I interface with engineers to make sure the right product gets built'. Tension occurs between PM and eng when engineers push back on a product spec or (even worse) an idea that never makes it to a written spec.

Read more in Qui propono?.

Stalled: Getting Development into Gear

At technology companies, Engineering and Development is the motor that keeps the product moving forward. Unlike real motors made out of metal, this one depends upon a lot of moving parts that are all-too-human, so it stalls a lot. A Development effort that sputters and stalls too often can lead to a product that falls behind the market. It is vital for a Product Manager to get involved and hands-on with the product motor if it starts to stall. Product Managers can bring a different perspective to the Engineering team that can make all the difference in getting stalled development efforts started. Read Stalled: Getting Development into Gear for some useful ideas that you can use with the team to make your product develop and improve faster, and therefore gain ground on the competition.

Are You Measuring What's Done or What's Left?

Johanna at Managing Product Development asks, Are You Measuring What's Done or What's Left? I'm at PNSQC this week. I gave my metrics talk yesterday, and something occurred to me: in traditional projects, we're used to measuring what's been done. In agile projects, we measure what's left to do. I just realized yesterday that the difference in how we measure makes a difference in how people feel about the project. The more you measure what's left, the more you can see the end of the iteration or the end of the project. It's also a lot clearer to see how many more iterations it will take if management decides to add more features. I'll be modifying my measurements--even for not-specifically-agile projects--to reflect what's left to do, not what's done.

Hiring Technical People

Johanna Rothman has published Hiring The Best Knowledge Workers, Techies & Nerds: The Secrets & Science Of Hiring Technical People, available at Amazon.

She writes, "Hiring knowledge workers, such as technical people, is different from hiring purely skill-based staff. Knowledge workers are not just the sum of their technical knowledge; they are the sum of their technical knowledge and the way in which they apply that knowledge to the product. The method with which they apply their knowledge is determined by how they use their technical skills for the product, how they manage their work, and how they manage their relationships with other people. Skill-based staff members have a set of skills they can apply the same way in almost all situations. Knowledge workers must adapt their knowledge to the situation."

Source Control HOW TO

Every successful product team needs automation, for product managers, developers, QA, and others. Developers probably have the most advanced set of tools; certainly source code control is critical. While product managers may not be using these tools, it's helpful to understand them and how source code control can prevent product delivery disasters. Eric Sink is writing a series on source code control. He writes:

"Our universities don't teach people how to do source control. Our employers don't teach people how to do source control. SCM tool vendors don't teach people how to do source control. We need some materials that explain how source control is done. My goal for this series of articles is to create a comprehensive guide to help meet this need."

Joel on Software: the book

I've been reading Joel Spolsky's articles on development and technology for years. Love his directness and his humor. I highly recommend his blog at www.joelonsoftware.com. His recently released book is called: Joel on Software: And on Diverse and Occasionally Related Matters That Will Prove of Interest to Software Developers, Designers, and Managers, and to Those Who, Whether by Good Fortune or Ill Luck, Work with Them in Some Capacity Here's a link to the book. Here's a link to the website.