I recently started a series on software development and the role of the Product Manager.  If you haven’t already done so, it might be a good idea to read Part 1 (Overview) before continuing.  In this post I’d like to write about the first step in the development process, namely Product Requirements, and the various sources of input that go into deciding what to build and how to improve your product.

As I started writing I realized the topic is just too big for one post, so I’m going to split it up into a few different posts:

• Part 2 (this post) will be about user needs as an input to product requirements.
• Part 3 will be about business needs and technology needs as inputs to product requirements.
• Part 4 will be about  the PM’s role in the Product Requirements phase.

Even though the focus here is not on what kind of product/service your company should develop and sell, I do want to briefly mention product/market fit, because it is probably the most important aspect to figure out to be a successful business.  No one talks about this better than Marc Andreesen, so I wanted to quote from one of his (now deleted) blog posts:

The quality of a startup’s product can be defined as how impressive the product is to one customer or user who actually uses it: How easy is the product to use? How feature rich is it? How fast is it? How extensible is it? How polished is it? How many (or rather, how few) bugs does it have?

The size of a startup’s market is the the number, and growth rate, of those customers or users for that product.

The only thing that matters is getting to product/market fit.  Product/market fit means being in a good market with a product that can satisfy that market.

With product/market fit figured out (no easy task), and a workable product to start with, it’s time to get serious about building and improving the product — and that’s the stage where this post starts.  At the heart of a good product roadmap stands a Product Manager that is able to strike a balance between user needs, business needs, and technology needs.  So let’s look at each of those in detail, starting with user needs.
(more…)

This week I was in Johannesburg for the debut of Tech4Africa, a conference about web technology in the African context. It was a fantastic experience, an opportunity to learn from and meet some great people, and I will most certainly be back next year (but hey, Gareth, let’s move it to Cape Town next year!). Yes, there were the usual small conference hiccups, but nothing that can overshadow the importance and significance of this event.

The mere fact that we were able to listen to speakers like Clay Shirky, Andy Budd, and John Resig, as well as some top South African thinkers & doers, and discuss with them the uniquely challenging opportunities that exist here in Africa, made this conference a winner. The content was mostly great, but the conference was more than that — it was about being inspired and energized about being in this industry, at this time, in Africa. You should follow Tech4Africa and its head organizer, Gareth Knight, for updates on the conference. And no matter where you live, you should attend next year. This event is here to stay.

I also had the great opportunity to speak on a web design panel with Allan Kent, Basheera Khan, and Mike Lewis. We took a User-Centered Design (UCD) approach to redesigning Payfine.co.za, a web site that allows South Africans to pay the many traffic fines they get every… well… every month or so.

We’ve never met each other before the conference, and we were all in different locations. So, since we had to do this remotely and in our limited spare time, we broke the process up into three distinct user experience elements and each took responsibility for one of the tasks: content strategy (me), interaction design (Bash), and visual design (Mike). We collaborated a lot along the way, but we decided to each lead the creation of one piece of the puzzle, and then put it all together in a coherent story (this was Allan’s job!).

The end result? Well, you should judge for yourself. Here is what Payfine currently looks like:
(more…)

In one of his characteristically brilliant essays, Paul Graham recently wrote:

I think most people have one top idea in their mind at any given time. That’s the idea their thoughts will drift toward when they’re allowed to drift freely. And this idea will thus tend to get all the benefit of that type of thinking, while others are starved of it. Which means it’s a disaster to let the wrong idea become the top one in your mind.

The importance of focus in a startup, or any other business for that matter, is such a basic principle that no one disagrees with it, but it is still such a difficult thing to get right.  One of the reasons is that you don’t want to stifle innovation, and some of the best ideas can come from a completely random project you went off to do in your spare time.

Whatever your feelings are about side projects that take you off your main focus, it is important to recognize them for what they are: distractions.  This doesn’t necessarily mean it’s bad, but let’s call it what it is — these projects distract you from your “top idea.”

For the products I’m responsible for at Yola, we have name for such distractions.  We call them “squirrel projects.”  If you’ve seen the movie Up, you’ll probably immediately know what I’m talking about.  If not, here’s a refresher:
(more…)

Almost a year ago I wrote a post to propose/summarize a universal model for product development.  I’ve now refined that model into what I believe is much closer to what the original intention was: a product development framework that is detailed enough to be practically usable, but generic enough to fit on top of any development paradigm (Agile, Waterfall, etc.).

I’ve decided to start a series of posts on software development and the Product Manager’s role in that process.  The first, this one, is a very general overview — it’s basic, yes, but necessary to lay the groundwork.  After that, I want to spend time writing down my thoughts on each of these stages in detail.

Why do this? Because I think the Product Management profession is finally starting to come into its own, and I’m hoping that through discussion we can, together, evolve a practical guide to what we do from day to day, something that is both flexible enough and rigid enough to be helpful without being constricting.  And maybe also just to force myself to think through this in detail and become more deliberate and focused on each of these steps.  I hope you’ll join the discussion!

I won’t be talking about scheduling, scrum methodology, or team organization in these posts.  The goal is to focus on the work that needs to be done — whether it’s being done by an individual or a core team is not the focus here, and will be different depending on the company, the philosophy, and the team.

So let’s start here — a diagram of a proposed universal model for software product development:

(more…)

“DStv: so much more user-friendly,” says the ad in the background as I try in vain to press the button on the remote control just right so I can pause my show and go get another cup of coffee. It probably has something to do with last straws and camels and stuff, but that ad finally put me over the edge and onto the computer to write about the user experience of DStv’s remote control for their HD PVRs.

It is often much easier to figure out which companies practice user-centered design and which don’t when they produce physical products as opposed to online interactions. Think about Target’s redesign of the prescription drug bottle as an example of deliberate design, and America’s 1040 Tax form as an example of what happens when there is little to no design input on a product.
(more…)

I’ve been thinking about Evernote and Dropbox, and the characteristics that make them successful freemium businesses.  Of course, a lot has been said about freemium, and Ning’s recent decision to drop that business model has placed it under renewed scrutiny.  But I don’t think it’s time to bury freemium just yet.  I wanted to write down some quick thoughts on what I believe are three essential characteristics of a successful freemium business:

1. Be patient with users.  Evernote’s cohort analysis shows that initial conversion rates are at about 1%, but once users have been with the service for 18+ months, that jumps to 4% — more than enough to be profitable.  And it’s not actually a bad thing to have free users for that long — at that point they are so invested that they’re not going to take their data elsewhere.  They know and love the product, so when they hit the storage limit, they’re comfortable with paying.
2. Have a natural (and inevitable) path to upgrading.  With both Dropbox and Evernote, if you use the product long enough, you’re going to have to upgrade — at some point you’re going to run out of storage.  If you don’t have a natural path to upgrading you need to create one, or you’ll find yourself in trouble.  Users will use your free product for forever and be happy with it.  You need to make it inevitable that a certain % users will hit one of your limits.
3. Have a great free product.  It might sound contradictory, but if your free product sucks, the switching cost will be very low.  Dropbox and Evernote are successful because users love the free product, so when they run up against the limits, the decision to pay is an easy one.

(more…)

I read quite a few excellent UX/PM posts this week, and wanted to make sure you don’t miss out.  So here are some excerpts from my favorite posts of the week.

User Experience Design in the Agile context

In Agile UX and The One Change That Changes Everything, Anders Ramsy writes about how user experience design can be adopted to fit the agile mold a little better.  He calls for less design up-front to basically embrace the MVP approach instead of fighting it:

The first and probably most fundamental change to flow out of starting to build earlier is that of chopping your up-front design phase down to a fraction of what it might be in a traditional model to allow for establishing a foundation of working software, and then evolving the rest of the product on top of that foundation. In other words, we go from Big Design Up Front to Just Enough Design Up Front.

The rest of the post is devoted to how to do that, including thoughts on lighter, conversation-centered documentation, and the importance of collaborative design.
(more…)

I just read an interesting New York Times article on “social reading” (Yes, People Still Read, but Now It’s Social), and it got me thinking about the future of reading, and the e-reader battle that’s currently going on, particularly between the iPad and Amazon’s Kindle.  And then I upgraded my Kindle software to v2.5 this morning, and it made it clear to me why I think the Kindle is a far superior reader to the iPad.

No one will deny that the iPad’s iBooks app has a nicer user experience than the Kindle.  It’s colorful and pretty, it has a nice bookshelf, you can turn the pages with your fingers, and, uh…  Well, that’s where it stops.  The two major issues with iBooks are:

• Since it’s a back lit display, it starts hurting your eyes when you read for too long.
• The battery life is, you know, not ideal…

Now consider the Kindle.  Though not as pretty to look at, you can tell that Amazon decided to focus on the reading experience.  You don’t have to plug it in all the time, and you can read it for hours without hurting your eyes.  But it is v2.5’s forays into social reading that really starts to set the device apart.  There are two features in particular that I think are brilliant:
(more…)