Software development and product management: Part 1 (Overview)

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:

Borrowing from and expanding on my original post, I want to make a few observations. First, 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 from the very beginning of the process. Once detailed requirements are being written, it largely becomes an Engineering and Product effort to ensure momentum and avoid the dangers of design by committee, best summed up by Dilbert:

• 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/Product Owner. A good product manager is not a dictator. He/she is a facilitator between all the different stakeholders of 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.
• The roles of the Responsible (R), Supporter (S), and Informed (I) are important to define for each of these steps.  Most important is that there should be only one “R” for each step.  This doesn’t necessarily mean it’s the person who does all the work, but it’s the person who is ultimately responsible to get the work done (with help from the “S”es).
• 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).

Summary of the different aspects of the model

The rest of this series will be devoted to detailed discussions about this model. My goal with this post is to be general and make one or two points about each aspect. So 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 with 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 what technical debt needs to be paid down. Having engineering and product working together is essential in good product development.
• Requirements gathering. Pragmatic Marketing, in a post entitled “On Reqs and Specs: The Roles and Behaviors for Effective Product Definition,” proposes some solid definitions 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.”
• Solution brainstorming. Once the problem has been defined and agreed upon, the team starts thinking about solutions, usually through some form of design thinking or abductive reasoning. 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. 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.
• Flow charting and wireframing. This phase starts to put some flesh around the second output document, 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.” At this point visual design is still left out of the picture, all you are doing is defining flows and interactions.
• High-fidelity mockups. In this phase, visual design gets involved to design the experience as it will look on the screen.  If there are pre-defined patterns and standards (as is hopefully this case), this could be a pretty light step, but I do believe it is important, even in an agile environment, not to leave this part up to chance.
• Technical specifications. Development can start before the full designs have been completed.  Once the flow and interaction are sorted out, you do in most cases have enough information to start task breakdown and 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, discuss, 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.
• QA, release, assess. After the thrill of releasing, 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? 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.

Where we go from here

So now that the stage is set, what happens next?  Over the next weeks and months, I’d like to write a detailed post on each of these phases, particularly from a Product Management perspective, and what the role of the PM/PO is during each of the phases.

There are, of course, lots of resources out there for Product Managers, but I’m hoping to talk more practice than theory here, and hopefully generate some discussion (and disagreements!) to help us reflect on our chosen profession.

PS Big hat tip to @justinspratt who gave me the nudge I needed to start this series.  He is the real deal, despite being Australian.