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:

• First, Amazon allows you to opt in to viewing popular highlights. This allows you to see when passages of a book you’re reading were highlighted by others who have read the same book.  It’s like a virtual book club, but instead of trying to get 6 people to agree on a book to read, you can connect with 100’s of readers who are already reading the same book.  This kind of connection really is where the Internet is at its most useful.
• Amazon also allows you to link your Twitter and Facebook accounts to your Kindle.  This means that you can highlight a passage that you’re reading, and share it with your followers, like I did this morning:

That is powerful.  It not only allows you to share what you’re reading and thinking about in real time, but it’s also great business for Amazon, since it provides a way for your followers to purchase the book right away.  Of course, even the Kindle packaging tells you that this is an experience built around passionate readers:

The differences between the iPad and the Kindle have larger implication as well, particularly in the field of Product Management.  Look, the iPad is gorgeous, it really is.  But it is an experience designed to contain so many different uses, that it is not possible to focus on doing one particular thing (like reading a book) extremely well.  The Kindle is singularly focused on readers, and that is why it beats the iPad hands down as an e-reader.

Dropbox did exactly the same thing to beat out their competitors — they focused on making file sharing as easy and convenient as possible.  They didn’t have all the features, but they made sure the features they do have has a superior user experience.  On that note, if you haven’t watched this 23-minute talk by Dropbox’s CEO where he discusses their business model, you really should.  It is inspiring and well worth it.

Hey, South African tech industry?  Meet me behind the rugby field at 15:00.  We need to talk.

I’ve been back in South Africa for 3 months now after 6 years working in Silicon Valley, and I think I finally figured out what’s been bothering me about the tech industry here ever since I got back.  The problem is that we have some serious Goldilocks issues going on right now.

This one is too cold

The first problem we have is a severe inferiority complex.

Remember: just because we’re not in Silicon Valley doesn’t mean we don’t know what we’re doing.  Like Morpheus says in The Matrix: “Some things are true whether you believe in them or not.”  We’re good at what we do.  We’re really good.  Why does it matter if anyone knows it at this point?  They will, soon enough.

I know that many of those dudes in San Francisco treat us like the little brothers of the world — adorable but not to be taken seriously.  But that doesn’t mean we have to grovel.  Who cares what they think?  Haven’t you heard?  Silicon Valley is dead.  You can be brilliant anywhere.  So we might as well be brilliant in the most beautiful place on earth.

This one is too hot

But we also have a second problem.  Some of us tend to overcompensate.  You see, since we have this inferiority complex, there is a danger in wanting to “show them a thing or two.”  So we livetweet from events that we’re not attending.  We write reviews of products we haven’t seen.  We fight about what the definition of a startup is, as if that matters.  We show up at conferences and give talks on who we are instead of what others can learn from our experience.

No, not cool.  There is no need to overcompensate.  We have some very unique skills, and we have the benefit of the element of surprise.  No one thinks the next Facebook is going to come from South Africa.  Let’s keep it that way — don’t let them know we’re here!

This one is just right

But there is an alternative.  We can make great products, build great companies, and take over the world without anyone even knowing where we’re from.  Does it matter where WooThemes are from?  It matters to us.  It doesn’t matter to anyone they sell their products to.

So, please.  Stop being apologetic about our skills.  Stop wishing we were Silicon Valley.  Stop pretending to be in Silicon Valley.

Instead, follow Seth’s advice.  And forgive me for quoting verbatim, but no one says this better than him:

Yes, I know you’re a master of the web, that you’ve visited every website written in English, that you’ve been going to SXSW for ten years, that you were one of the first bloggers, you used Foursquare before it was cool and you can code in HTML in your sleep. Yes, I know that you sit in the back of the room tweeting clever ripostes when speakers are up front failing on a panel and that you had a LOLcat published before they stopped being funny.

But what have you shipped?

What have you done with your connection skills that has been worthy of criticism, that moved the dial and that changed the world?

Go, do that.

There is a very interesting and healthy debate going on in the Agile Development world about Minimum Viable Product (particularly in startups).  Before I get into the topic I’d like to address today, I just want to do some positioning and say that in this debate, I currently (but am open to being convinced otherwise) side with writers like Andrew Chen (read his excellent post, Minimum Desirable Product) and Jason Cohen (read Releasing Early Is Not Always Good? Heresy!).  The other side is represented by posts like this one by Jeff Atwood: Version 1 Sucks, But Ship It Anyway.

While the debate is still ongoing, I’d like to write about a very specific related aspect, namely product development process (and those of us who would like to argue for fairly strict compliance to it).  Two recent blog posts address the topic of compliance directly, and I wanted to reference them and then write a quick response on why I think process is so important, especially in agile development.

The first is Seth Godin’s Dancing with entropy.  His rant on compliance actually inadvertently includes a pretty good description of what Product Managers do:

People are often paid to enforce compliance. The job is to ensure that everything is in its place, that errors are zero, that things are delivered on time and as expected. The random event is a problem, something to be feared and extinguished.

His main point seems to be that you should embrace the unknown, and “dance with it”:

Most people, though, the ones with great jobs, are in the business of dancing with entropy, not creating it. Take what comes, sort it, leverage it, improvise and make something worthwhile out of it.

I’m assuming he refers here to the definition of entropy as “a measure of the disorder or randomness in a closed system.” This is a great sentiment and we should all be able to deal with the unknown, but in practice, creating Ordo ab Chao during development can only happen effectively with proper product process behind it.  You can’t dance with entropy without bug tracking, if you catch my drift.

The second is a post by Aslam Khan entitled Forced compliance is an obstruction to discipline.  I respect him a lot for his forceful call for self-discipline in development, and I don’t doubt his sincerity at all when he writes:

Surely, we have learned enough from spectacular failures that governance does not give people an opportunity to exercise self discipline. When you give a person a chance to develop personal discipline, then forced compliance is unnecessary. With forced compliance, we force people into ignoring their own discipline because the system will “sort” it out for you. It breeds an attitude of “the system failed me and it’s not my fault”.

This is an ideal situation, and I agree with Aslam that personal responsibility is an essential quality for any developer — and PM, and designer, and human being, for that matter.  But personal responsibility is just not going to get you all the way there.  And by there I mean a product that is successful in the eyes of the company and its users.  I’m not arguing for the perfect product — there is no such thing.  But there is such a thing as desirable products that work the way they are supposed to and meet customer needs.  And for that, you need more than personal responsibility.

It is a mistake to think that process/compliance slows down development or inhibits innovation.  Compliance puts boundaries around what is within scope, and allows you to know when the product you’re working on is ready to launch.  Compliance also doesn’t mean that you don’t trust your team, or that you think people aren’t capable of working on their own.  It’s not about keeping tabs on people, it’s about making sure the product doesn’t get out of control.

By compliance I don’t mean an inability to roll with the punches and remain agile, but that a certain degree of process is needed.  In an earlier post on the software product development lifecycle I go into more detail on what I believe is a good process for product development.  I also discuss three outcomes recommended by Pragmatic Marketing: Requirements, Functional Specifications, and Technical Specifications.  I do believe we need this level of process, and compliance to it, to build great product.  We should embrace it, not fight it.  You know, dance with it.

As a Product Manager, I understand the Minimum Viable Product (MVP) concept, decisions to de-scope rather than delay, etc.  But too often MVP’s go out into the wild missing that all-important middle “V”, so you end up with, well, minimum products.

An example I came across recently is the sign-in process on Comcast.com.  First, a little background.  Comcast recently deployed a product they call mySIGN-IN.  According to their FAQ page:

mySIGN-IN is a unified sign-in system that lets you use your existing email address and password to access participating Comcast sites. When you sign in to any participating Comcast site, you’ll be conveniently signed in to the other sites that you use.

That all seems well and good, but the actual sign-in experience shows what happens when features go out without proper integration.  The sign-in process now happens on two separate pages:

Step 1: Enter email address

Step 2: Enter password

Two things struck me immediately about this experience:

• There is no reason to split the sign-in process into two screens.
• The visual design of the two pages are completely different.

Wanting to give Comcast the benefit of the doubt, I started looking into this a little more (because, you know, what else am I going to do on a Sunday afternoon apart from listening to Amos Lee on vinyl).  I thought that maybe this was an acquisition, and they are just taking some time on the integration.  But no, as far as I can tell, mySIGN-IN is not an acquisition — it is an internally developed product.  So I think this is what happened:

• A separate Comcast division designed and developed the mySIGN-IN feature
• The different Comcast properties started implementing the feature onto their sign-in pages
• Due to technical reasons, the pages had to be split for Comcast.com
• There was no UX oversight to ensure design consistency (or no resources available to make necessary changes)

Now, it does appear that someone at Comcast realized that this is not an ideal experience, and decided that explaining the changes to users is in order.  It’s a noble idea, but as we know, most users don’t read anything that’s not inside or next to a text box.  Either way, here are some of the tool tips that were added:

That first tool tip really bugs me:

Due to some recent security improvements, we now require you to enter your user name and password in two separate steps.

That just doesn’t seem right to me.  Due to “security improvements”?  I may be missing something from a security perspective, but I just don’t see why the sign-in information can’t be passed through securely without splitting up the pages.

What this means for product managers

I don’t mean to pick on Comcast.  This type of thing is very common, and I’m sure I’ve made similar decisions in the past that results in a user experience that’s not ideal.  But I do think this example can teach us a few things about product management:

1. Product owners (those responsible for individual features) need Product Strategists to ensure UX consistency (see this article from Pragmatic Marketing about different Product Management roles).  mySIGN-IN was clearly design in a vacuum, which could have been ok if there was someone who made sure the user experience stayed consistent across properties.
2. Don’t leave out the “V” in the MVP.  I believe that Comcast didn’t launch a minimum viable product.  Splitting the login pages into two screens is unnecessary and confusing to users.  The MVP might be an incomplete product, but it should never feel incomplete to users.  Users shouldn’t be able to notice that something is missing.  There is clearly something missing here.
3. Tool tips won’t solve everything.  If I had a penny for every time I heard the phrase “We’ll just add some content to explain that to users…”  As a general rule, if you need a tool tip which links to an FAQ page to explain something to users, your design is probably not intuitive enough.  It cannot be stressed enough that users really don’t pay attention to a lot of text.  The average user sees a form field, and starts typing.  Your user experience should support that behavior, not try to change it.

I have no doubt that Comcast had the best of intentions here, and that mySIGN-in is probably a cool feature.  But without proper product management, even inherently cool features can become frustrating user experiences.  Let’s be the users’ champions when it comes to launching new features.

Introduction

I’ve seen a lot of product development processes over the years, and as with most things, it’s important to take what works for your organization, and leave what doesn’t work.  These processes go by different names, mainly various combinations of the words Product Development Lifecycle (PLC or PDLC).  There are also a common thread through most product development models, and this article assumes that the reader has a basic understanding of the general five steps of product development:

Great work has been done on fine-tuning the details of the PDLC, but it has always bothered me that there is not one universal model for software product development that fits two main criteria:

• Specific enough so that it gives real and practical guidance for product managers and organizations on how to design and develop good product.
• General enough so that it can be applied to all different types of software development methodologies (Agile, Waterfall, Spiral, etc.)

And that is what I set out to do in this article.

A universal model for software product development - first draft

So, here is what I have come up with so far.  I hope that this initial attempt at a universal model for software product development can generate some discussion on what works and what doesn’t, what’s missing, how it can be refined, etc.  Below the illustration I go into more detail on each aspect of the model (click to enlarge).

There are a few assumptions that are important to note about this model:

• Regardless of the development methodology, representatives from Product, Marketing, Business, Design, and Engineering should be involved to some extent in each step, all the way to the writing of the technical specifications, after which it largely becomes an Engineering and Product effort.
• Having said that, it is important for one person to own this process (i.e. be accountable for its success) from start to finish, and that person should be the Product Manager.  A good product manager is not a dictator.  He/she is a facilitator between all the different stakeholders in a product, and the really good ones are able to get through this model on time and on budget, every time and with as much consensus between groups as possible.
• This model is designed to work for any organizational structure, project size, and timeline.  If the project is large, more time can be spent on each step.  If the project has a tight timeline, it doesn’t mean that you will skip the “Iterate” part of “Design + Iterate.”  It just means that you will spend less time on it (more on that later).
• I highly recommend reading Adam Nash’s post entitled “Guide to Product Planning: Three Feature Buckets.”  He recommends that every feature release should have a combination of what he calls Customer requests, Metrics movers, and Customer delight.  I am in total agreement with him, and this is an important underlying assumption for this model to work effectively.

Detailed discussion of the different aspects of the model

Let me start by saying it is possible to write a separate blog post about each of the bullet points below.  My goal here is to be general and make one or two points about each aspect.  If there is interest I could expand further on any of the concepts in the model.  So with that said, let’s look at some definitions and implications of the model:

• The starting point - identifying needs.  At the beginning of any project (new or iterative), it is important to gather and synthesize input from three different sources:
  • User needs.  Everyone needs to have a good understand of the market, the target segments, and their behaviors and attitudes.  There’s not enough room to go into detail here, but it is important to look at four sources of user input: market research (segmentation, etc.), user experience research (usability studies, ethnographic explorations), site analytics (behavioral analysis), and customer support (call transcripts, interviews of CS reps, etc.).  Having this common understanding allows the organization to build products that matter to users.
  • Business needs.  User experience practitioners too often neglect the fact that well, your site has to make money!  Revenue goals are not a good excuse for bad design, and that attainable revenue goals are essential to push the organization to design good product.
  • Technology needs.  Engineering needs to be at the table from the start.  They know the limitations of the product, they know what needs to be fixed, they know where the architecture can improve.  Their up-front input is essential in good product development.
• Problem statement (Requirements).  I am indebted to Pragmatic Marketing, particularly a post entitled “On Reqs and Specs: The Roles and Behaviors for Effective Product Definition,” for the definitions I use for the three different documentation outcomes in this model: Requirements, Functional specifications, and Technical specifications.  The first outcome from the discussion and synthesis of needs is a common understanding of the problem statement you are trying to address, which takes the form of Requirements.   A requirement is simply a short statement of the problem, and Pragmatic Marketing recommends the following format:  “Our preference is the Requirements That Work format: [Persona] has [problem] with [frequency]. It forces product managers to explore the problem, not the solution, and helps the design team understand the context of the problem.”
• Diverging and converging design thinking. Once the problem has been defined and agreed upon, the team starts thinking about solutions.  There are three important aspects of this phase, which is often called Product Discovery:
  • Start with blue sky ideation (divergent thinking).  At this point, don’t limit solutions by what is technically or otherwise feasible.  Spend time dreaming about the product - this is where innovation happens!
  • Relentlessly prioritize (convergent thinking).  This is the part of the process where nonsensical ideas are thrown out, and the team consolidates around a few possible solutions to the problem that can be further explored.  Remember: there is no commitment to implementation or specific designs yet at this phase.
  • Apply the technology filter only after the ideation phase. I wanted to explicitly call out the roll of Engineering during the solution discovery phase.  It is a mistake to bring Engineering in too late in the process.  There is a very important technology filter that needs to be applied during prioritization.  What is technically feasible?  If something is currently not feasible, what would it cost to build the right architecture?  Those early inputs can save a lot of headache down the road.
• Functional specifications. The second output document from this model are the Functional specifications, which Joel Spolsky defines as follows: “A functional specification describes how a product will work entirely from the user’s perspective. It doesn’t care how the thing is implemented. It talks about features. It specifies screens, menus, dialogs, and so on.” Note that we’re not talking about technical implementation yet, that comes later.
• Design and Iterate.  Everyone designs a product, but it is sad to see that when time/budget gets tight, iterating on it before it goes live is often the first part of the process to fly out the window.  It cannot be overstated how important it is to prototype and test your designs before they go live.  And not having time is really no excuse.  If you have no time, make a paper prototype and test it with three of your friends over coffee in the evening.  You’d be surprised how much value this can add.  Boxes and Arrows has a great article on prototyping and how to integrate it with your design process that’s well worth the read.
• Technical specifications. Only once you have a set of Functional specifications and a Prototype of some form (even if it is very low fidelity), it is time to work on implementation.  Quoting Joel Spolsky again, “A technical specification describes the internal implementation of the program. It talks about data structures, relational database models, choice of programming languages and tools, algorithms, etc.”
• Build and launch. If you’ve done the upfront work, this could actually be the easy part.  You have a set of requirements, a prototype, and a detailed set of specifications to work with, so now it’s time for the Engineers to work their magic and build the product.
• Assess.  The assessment phase is extremely important and often overlooked.  It is important to define your measures of success upfront, and then follow up to see if you’ve met those goals.  How do users respond to the product?  Are we meeting revenue/engagement goals?  Are there bugs that need to be fixed?  What can we learn from how users interact with the product to give us ideas for new products?  I’m also an advocate for using the same four sources of input we discussed earlier (market research, user experience research, site analytics, and customer support), as opposed to relying on only one methodology, like a 3-week A/B test.  More on the dangers of that in one of my earlier posts.

Implications and final thoughts

I think this is a decent first attempt at a universal model for product development that can be applied to any timeline or organization type, but it is far from perfect.  I hope that the product management community can come together and refine this so that we can end up with a credible, relevant, and useful model for building great product.

Eventually, I’d like us to build out this model so that it is more easily adjustable based on certain constraints that might exisit within a project, such as budget, time, development methodology, and team size.  But let’s see if this one passes the smell test first…

With the three recent big stories in Facebookland (the FriendFeed aquisition, real-time search, and now the test launch of Facebook Lite) it doesn’t take a rocket scientist to figure out that Facebook is going hard after Twitter. (Update 1/16/2010: Facebook just rolled out “via” as their version of Twitter’s “retweet”. That, combined with recent changes to their privacy policy to make the platform more open, are two more clear examples of Facebook’s “Become Twitter” strategy)

What is more difficult to understand is why they are doing it.  Maybe it’s a personal vendetta because of the failed acquisition talks?  I just don’t see the business reason for this.  Here’s why I think Facebook should forget about Twitter and focus on making its own platform great:

Different target markets

It is well known that Twitter skews heavily towards younger tech-savvy users, with the rest of the population finding it hard to see the point.  Facebook, on the other hand, is increasingly being used by an older demographic.  The fastest growing demographic on Facebook is women over 55.

Why is all this important?  Because regardless of what Facebook wants to be, the demographic that is settling in on the site for the long haul is different from the Twitter user base — and they have totally different needs and behaviors. At this point, Facebook is too established as a brand to be able to force their product onto the target market they want.  And why would they even want to?  They have access to a much larger user base than Twitter.  Which brings me to my next point…

Always compete on your strengths

The mistake that Facebook is making is that it is trying to be Twitter for a user base that does not want Twitter.  Not convinced?  Go to http://www.brandtags.net and look at the brand clouds of word associations that people make with Facebook and Twitter.  For Facebook, you get words like Communication, People, Stalking.  For Twitter, you get words like Pointless, Stupid, Useless.

Now, of course Twitter is none of those things, but it shows the enormous gap in brand perceptions.  Why would you want to move a powerful people connection platform closer to something with a niche market that a majority of people find useless? There are a bunch of other Twitter statistics coming out lately that prove the Twitter niche factor: 5% of users account for 75% of the activity, 60% of US Twitter users abandon the site after a month, and 24% of all tweets are from bots (ok, that last one is irrelevant to this discussion, but still interesting).  And there’s also this interesting conversation on Mashable that clearly shows the differences between Twitter and Facebook usage.

The bottom line is that Twitter is for information sharing, Facebook is for life sharing.  That is what people are using it for — sharing photos, videos, those annoying pokes and quizzes, keeping in touch with friends all over the globe, lurking on profiles of people you used to know way back when.  That is the strength of Facebook, and that is what they should focus their platform on.

So what should Facebook do?

So here is my advice to Facebook: go where your users are.  Understand how they use the site, what their needs and behaviors are.  Go visit them, talk to them, watch them navigate around, understand why they are there in the first place.  And then enhance your platform to fulfill those needs.  Build new ways to feel closer to the people in your life.  Make it easier to share and discuss media.  Build families-only mini-communities.  Who knows what you can come up with if you just understand your users and build a web site for their needs?

Seriously — let Twitter be Twitter, forget about them and don’t force your users into that kind of experience.  Don’t try to be “status updates for everyone.”  Be a platform that lives up to the value proposition on your home page: “Facebook helps you connect and share with the people in your life.”