Welcome to Product Management Challenges!

03004 Beta Software: Setting Expectations

Nothing can be better for your software than to have a new release go through a beta program where customers (even prospects) put the software through its paces in a real-world environment. When the release is announced, not only are you confident that most major problems have been identified and rectified, but you have case studies for your marketing collateral, endorsements for your press releases, and best of all, positive references ready for interviews with the media.

However, while those who make quality their career may clearly understand what beta software means in terms of number and type of bugs and other issues, this is a murky area in the minds of your beta users and the executives they report to. It is critical that you set expectations with your beta program participants if you want the experience to leave a good impression. This lays the foundation for acceptance in the marketplace, and can mean the difference between good reviews in the trade journals and getting trashed for problems that were never serious in the first place.

In my experience with beta software, I have seen a common pattern of problems, and responses to those problems, that has led me to set expectations in a very specific way with beta customers in order to leave a lasting impression of good quality software. This approach is described below.

(more…)

03003 The Development Plan: a Dose of Reality

When it comes time to create the plan for the software development phase of the next cycle, Product Managers often find themselves faced with the same hurdles again and again. This is partly due to the typical personalities found among programmers and software engineers, who demand precision, details, and a clear answer for everything.

As planning jumps quickly to the details, the same objections are raised each time. How can we plan for bug fixes when we don’t know how many there will be? How are we going to rewrite the code in Java when there isn’t enough time with the release dates you’re giving us? We can’t just refuse when Marketing asks for our help with trade show demos!

I have witnessed countless planning sessions where these questions caused progress to grind to a halt. The fact that there were no satisfactory answers was used as a justification (meaning excuse) for loose planning, not setting hard and fast completion dates, or lengthening the development cycle. What resulted was confusion, slipped dates, extensive delays (like taking twice as long as originally promised, always a confidence builder), and the failure to implement significant improvements in architecture or capabilities for years at a time. All this while the competition continued to make progress.

I have also seen software development plans that address all the typical questions and more, and resulted in stable, predictable development that met commitments and moved the product forward. Here are some tips to break through common barriers to good development planning.

(more…)

03002 Requirements: How Much Is Enough?

Requirements are the challenge every Product Manager faces. Each software company manages to deal with the requirements headache more or less successfully, and headache - or heartache - is exactly how many people look upon the whole process.

Yet viewing requirements as a necessary evil can get you into trouble. After all, requirements are how your product moves forward, and such a critical aspect of your business must take center stage and have the full and enthusiastic backing of the entire organization, from sales and marketing to engineering, consulting, and customer service.

Given that you must face this necessary, painstaking process, the question becomes: How much pain should it take? You want to find the minimum amount - the minimum daily requirement, so to speak - that will fulfill your development function’s nutritional needs. There’s no sense in overkill, because the developers won’t necessarily listen to the details anyway.

So here are a few guidelines to help you get the most return on your investment in the requirements process, and choose the appropriate path for your organization in an industry that demonstrates widely different levels of effort from company to company.

(more…)

03001 Why Is the Soft Stuff So Darn Hard?

When you’re a software Product Manager, using soft skills is critical to success as you work to make things happen between groups and individuals with agendas, perspectives and personality types that are at odds with one another. CEOs and executives find themselves faced with the same challenge. It’s a case of same planet, different worlds, and you’re the lucky one whose job depends upon making those worlds mesh.

Yet the use of these same soft skills is so often ignored and neglected by the management team. It’s easy to forget about them when urgent items such as deadlines, bugs, costs and sales cry out for attention.

Imagine how much better it would be if the software engineers thoroughly understood the requirements that the business consultants submitted, with both sides understanding the limitations of their own perspective while respecting that of their counterparts. Well, if you’re one of the lucky ones who can say this is true of your company today, I’ll lay you money you can easily name other places you have worked where nothing of the sort ever happened.

The price we pay is poorer software, and nobody has the luxury of letting the product fail to achieve its potential, lest the competition pull ahead of you.

So here are a few suggestions to help you harden your soft skills and put them to use for the good of the software product and ultimately your career.

(more…)