ProductMarketing.com

Six technical practices you should know about

It seems ignorance is bliss for many in tech companies but it really doesn't matter if you're a product manager, a product marketing manager, or a product owner, there are six technical practices you should know about: Version control, Continuous integration, Automated testing, Refactoring, Simple design, and Collective code ownership. If you're in a tech role--or work with technical people-- you should understand these concepts, and make sure they're in use by your team.

(Oh, and also, you need to know the characters of Battlestar. Of course, you already know Star Trek and Star Wars.) (Plus, who Douglas Adams is.)

Let's play "Req or Spec": import text files

There's often confusion about what is a requirement and what is a specification. Let's play "Req or Spec." Is this a requirements or a specification?

Which is this? How would you improve it? Add your comment below.

See On Reqs and Specs for more.

Join me later today for Role of Product Management When Development Goes Agile with Rich Mironov of Enthiosys on November 6, 2009 at 10am-11am PST (1pm-2pm EST). We'll explore the new Pragmatic Marketing framework with focus on agile teams.

Some old material and some new stuff. Maybe even some new jokes!

Let's play "Req or Spec": duplicate images

There's often confusion about what is a requirement and what is a specification. Let's play "Req or Spec." Is this a requirements or a specification?

Which is this? Add your comment below.

See On Reqs and Specs for more.

It's always about the problem

In our training classes, we emphasize the importance of solving market problems. Describing problems encountered by our target personas. It's the problem that drives product requirements. Yet we've become an industry of feature-speakers. "I want this and this and this and this!" Wait! What is the problem??

My friend Luke Hohmann wrote about this in his post "Market problems are still THE problem — even when you’re Agile!"

As teams embrace agile methods, some seem to have jumped backwards a decade, getting back to the thinking that opinions drive feature decisions; this is just wrong. Use market facts to uncover problems that customers are willing to pay to solve. Perhaps it's the pace of agile development, needing new items for the backlog every other week. Or perhaps it's a shift in the power of the "team" over the power of market facts.

If you're a product manager, you need to be delivering quantified market data to your product team; if you're a developer, you should demand it. Otherwise, the team will use their opinions of what they think people want. After all, in the absence of market facts, he who owns the compiler wins.

Got Scrum?

If you haven't heard about it, Scrum is the most widely adopted development planning method in use today. (Well, actually, "hybrid" is the most commonly used method; that is, a hybrid of XP, Scrum, waterfall, and others.) Usually about half of the people attending our Requirements That Work seminar are adopting Scrum. Requirements That Work focuses primarily on requirements and the artifacts of planning, product managers are also interested in the mechanics of agile development.

If you want to know more about Scrum, there are many books and websites available with information--often too much information for what a product manager needs to know. This video does a very good job of introducing Scrum in a very short ten minutes.

Take a few minute to learn more. You may find that these techniques can be used in your product planning regardless of whether your company has adopted Scrum or not.

on distributed teams

It's challenging to build a great product even when you have a small team working in a single office. The bar is already high enough! But let's make it even harder, shall we? How do you build products with a highly distributed team?

In my first job as product manager, I had a team located in LA while I was in DC. Once a month, I traveled to LA on the Monday morning flight, spent the week with the team, and then came home on the Thursday red-eye flight. After a while I started to resent it. I know, I know; they were a team of ten and I was just the one person, so it made logical sense that I go to them. When we added offices around the world, it seemed that I was the one who stayed up late to talk to one office and woke up early to deal with another office. I was burning the candle at both ends.

It makes logical sense. You know, “The needs of the many outweigh the needs of the few… or the one.” But logic doesn’t always work, does it?

Luke Hohmann of Enthiosys may have the answer. You can distribute teams successfully but only if you also distribute the pain. Read his solution in Distribute the team? Distribute the pain!

on the demo (positive feedback)

Chores! I'm funny about chores--like I'm a ten-year-old or something. I'm a procrastinator and my wife knows it so she praises me when I do a chore that I've been putting off. Even though I know I'm being patronized, I still like the praise.

When was the last time you praised your development team? For that matter, when was the last time you said anything positive about the product to the people who create it? Have bugs, design flaws, unhappy customers turned us into shrieking shrews?

Facebook recently passed a milestone: 10 billion photos posted online. They write:

To celebrate, we got a bunch of cupcakes and handed them out to our engineering and operations groups. One of our engineers calculated that if we had gotten one cupcake for each of our photos, and lined them up side by side, the line could reach halfway to the moon.

Do you and your team celebrate successes? Or is it just one week after another of slogging through the backlog? The Friday Demo is the day to celebrate. Look what we've done, ma! The team has been working hard so make sure you take the time to appreciate what they've done. Oh, and give them a chance to give YOU praise for the customer visits you've documented and the context you've provided.

"Sandwich every bit of criticism between two layers of praise." -- Mary Kay Ash

on beta testing

Quick! What's the second word in "beta testing." If you said "testing", you're right. That's why beta testing should be run by the testing people in QA. However, as Paul Young writes,

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.

Product managers are often involved with beta testing because product managers want to validate the usability of the product (hint: do it much sooner), they want to show the product to some key customers, or maybe they just know more customers than the QA people. Read Paul's description of 5 types of beta. Great stuff. Are there more?

nothing seems difficult

Building products isn't factory work; it's a miracle. One of my favorite sayings is "nothing seems difficult to the people who do not have to do it."

Bill Miller provides an answer to why it takes so long to deliver production products in Why It Takes So Long. Share it with your team and your management.

on offshoring

My friend Scott Sehlhorst offers a detailed view of what it takes to make outsourcing work. He explains that there are essentially four different models for managing a software development project with respect to onshore and offshore roles. Read Making Offshore Development Work.

I find that there's a trade-off that isn't appreciated or understood by the advocates of offshoring. The trade-off is between domain knowledge and required detail.

Do you want it quick or cheap? Pick one.

You can be brief and agile with a group that understands the product and the domain; you must be extremely specific when dealing with people who do not.  And with this required detail comes more time in meetings and more time writing artifacts--and less time building product.

Whether onshore or off, a product team needs to understand the personas and their problems. If you're dealing with people who "just want to code," someone on your team will have to detail everything exactly as you want it delivered.

where does design belong in your organization

A product designer is--or should be--a valued member of any product team. Cooper's Kim Goodwin writes,

These days, more and more companies are recognizing that design and innovation are essential to their strategy and bottom line: effective design sells products and services, improves your position in the marketplace, and turns customers into loyal advocates for your brand. If you've gotten your organization to this point, take a moment to enjoy your success! Creating demand for design is no small achievement. Unfortunately, to reap the full benefits of design, you probably still have a lot of work to do on your organization's structure, processes, and culture.

Read more in Where does design belong in your organization?

on geeks and flakes

Scott Sehlhorst reminded me about Geek Marketing 101 by John Dodds.

John writes,

It is so named because I see amongst many geeks a pervasive misunderstanding and consequent distrust of what marketing is, and a failure to recognise that much technology marketing is no longer geek to geek since complex products are increasingly being bought by non-geeks. Of course, these observations are equally applicable to geek to geek and non-geek businesses.

Scott adds,

Don’t let them know, but we’re on our way to understanding how this stuff works.

I spend time with marketers and developers constantly yet I often forget about the chasm between the two. A marketer says "Talk to me like I was a five-year-old," a phrase which translates for a developer to "I don't know enough to work here."

Technical people are often obsessed with technology--the "how" of the product--but people don't care about the 'how' until they understand the 'what'. Marketing people are often obsessed with competitive positioning, the unique selling proposition--they are more concerned with the "what" than the "how"--but customers don't really care how you're better until they understand what you're gonna do for them.

Geeks and flakes need to meet in the middle: what are we going to do for customers?

more on schedules

  Why are projects so late? Joel Spolsky writes:

A huge number of technology projects go wrong. This is news to no one. Whether you run a software company with a number of ongoing development efforts or you have a nontech company that hires consultants here and there to provide systems integration, chances are you've bumped up against this problem. Delays, blown budgets, and outright failures are so common in the software world, in fact, that it's hardly newsworthy when a project is years late and millions over budget.

It seems to me that too many managers think of programming as factory work while Joel obviously sees it as art. And I agree with Joel. Whether you're writing code or a blog or a book, you need a creative environment. And working 80 hours a week doesn't help. Trying writing when you're not inspired--and then try it when you're tired too.

Nothing seems hard to those who don't have to do it.

on unrealistic schedules

Bill Miller writes about unrealistic schedules:

I often wonder why software teams always seem to be committing to unrealistic schedules. You know when the sales team signed a contract with a customer to deliver functionality on a date without ever asking the engineering team whether it were possible. Never mind the roadmaps identify an entirely different set of functionality than what was committed. And guess what? The product roadmaps can’t change either; the sales team has signed contracts on that functionality too. 

Product managers, sales people, marketing departments, and executives make commitments all the time--and often they're unrealistic. We commit to a roadmap and then change it. We can't really commit to schedules when the feature-set keeps changing--but then we commit anyway. Yeesh. We have long advocated time-boxing as a method for balancing the schedule and commitments. Come to our Requirements That Work class to learn an agile approach to product planning.

Years ago, the president of a startup asked the product manager to commit to an aggressive date. The product manager discussed it with the dev lead and the whole team and agreed that, yes, they could make the date but it involved a fair amount of overtime. The team agreed to work Saturdays until the project was complete. When the president announced the decision that development would work Saturdays, he also committed the entire sales department to work Saturdays until the project was complete.

The moral: being a team-player means that the people making the commitments should have some skin in the game too.

1001 things that a professional should know

James R. Stoup offers these Things Every Programmer Should Know For Their First Job:

Hindsight being what it is, here are some lessons I have learned since entering the ranks of professional programming.

These tips are especially helpful for the new employee with years of experience who wonders, "Why isn't everyone listening to me?" New hires first have to prove themselves. If you reflect on your own behavior towards new hires in the past, it's obvious but you don't notice it when you're the new hire.

One tip (that I've been slow perhaps to learn) is silence never goes out of style.

Do Techies Really Know How Their Product Is Used?

Personas, actors, meetings, discussion, voice of the customer? These are all methods that we use to show developers and engineers that they are not the customers of our products. Bonnie Rind explores this further in Do Techies Really Know How Their Product Is Used?

Are we ready to ship?

The problem with “quick and dirty” is that dirty remains long after quick has been forgotten.--Steve McConnell

Reginald Braithwaite posted this to the Toronto PMA:

Try this experiment: go to an engineer, and say "I don't care, your
career is not on the line, it is more important that we have a
quality product and happy customers. Now: are we ready to ship? If
not, when do you think we will actually be ready?"

Now go to another engineer. Tell her that vacations and weekends are
cancelled until we ship. Tell her that hitting our ship date is the
only thing that matters, slipping dates is for losers. Explain that
we have made commitments in the press and that the President will be
embarrassed and angry is we miss our date. Now, ask her if we are
ready to ship.

Is quality a variable? As Reginald points out, quality is the variable when dates and features are fixed... and careers in jeopardy. Timeboxing is the only solution that I know of that consistently gets good results.

Time is so much less important than we generally believe; urgency is typically in the minds of the vendor rather than the market. So remember, you never get a second chance to make a first impression. Ship less or ship late but don't ship poor.

Agile vs Waterfall debate

It seems no amount of process can overcome dysfunction. Perhaps the biggest challenge of developing tech products is respect among the team members. Or as we say in Requirements That Work, "friends build products."

Joel St-Denis writes in the Agile vs Waterfall debate: It was interesting to see that 2 of the companies in question had success in moving from a Waterfall to Agile methodology and both Product Management and Development had made the transition with success. On the other hand, 2 of the other companies had found challenges, and continued to struggle with the shorter sprints, or scrum approach, to Agile. The consensus seemed to be that there was a lack of respect between the PM and Dev groups in the companies which had issues, and this led to both departments pointing the finger at one another for delivery failures.

We commented on the role of product management in agile environments in Extreme Product Management with more specifics in how to deliver products people want to buy in an agile development environment.

Regardless of the development methodology, product managers should serve as conduits of market information. Too often we're attempting to control product development through rigorous requirements and a comprehensive Gantt chart. Instead we should influence with market information in the form of stories and personas.

Ten active listening skills

Active listening is about more than gaining understanding. Active listening is about giving. Giving assurance that you understand someone's needs. Giving confidence that you will address those needs. Giving feedback and acknowledgement that someone's input is valuable. If you haven't tried active listening, you may think it is a passive, receptive activity. Here are ten active listening skills that will help you, your customers and your team from Tyner Blain.