Part 3: The Product

Previous article: Part 2: The People

For many years, I was also the product manager for my engineering team's products. This dual role was definitely challenging, but it also honed my ability to identify value worth implementing. Product teams are always filled with competing opinions about what to build, when to build it, and how much depth of implementation is needed to make it good. Early in this role, I was introduced to Pragmatic Marketing and find their structured approach to product management cuts through the subjectiveness of managing product development. One of their famous phrases is "Your opinion, although interesting, is irrelevant." This reminder to stay fact-driven in product management is paramount to delivering value to market that produces the highest level of return on investment. You'll also be doing this with the least wasted capital, time, and effort (Be Lean!).

In this article, I'll walk through the process of collecting product requirement candidates, assessing their value, prioritizing the order of delivery, and delivering them back to the market. This is generally the domain of product managers, but there you might see aspects of sales, marketing, engineering, and delivery or service in this pipeline. If you're using a Servant Leadership model, make sure you're also enabling cross-departmental (networked) communication strategies since stovepiping and gatekeeping will destroy your ability to get the right information to the right people so they can build things quickly correctly.

Product Management

Product Managers will have slightly different job descriptions from one company to the next, but generally speaking they make sure a product or collection of products ("product line") are contributing to the overall success of the company. In the context of this article, they function as the conduit and translator between the customer personae and the internal process for developing and shipping value. Internally, they also interface between the product development organization and other corporate functions, especially Marketing, Sales, and Finance.

One key to developing a great product are the techniques built into Design Thinking. In the product manager role, engage with your customers early in the development cycle so you know exactly what your customers' problems are. If possible, experience them first-hand. For many years, I managed product development for a network management tool used by not only highly technical engineers, but also less technical customer service (call center) representatives (CSRs). I sat down next to CSRs and spent hours listening to the dialogs as they worked through various issues. Sometimes they were using my product, sometimes a different one, and sometimes multiple tools on the same call. This direct observation was invaluable during later conversations with the customer stakeholders (in Part 2, I call these specific people Beneficiaries) and then guiding the engineers to build more relevant implementations that solved the real problems.

Sit down with customer executives and managers and discuss how expensive their problems are for them as well. Keep in mind that sometimes the expense is in lost revenue (opportunity cost, uncompetitiveness, and customer churn) and sometimes it's a literal expense (labor, customer retention programs, or performance penalties). Working through the workshops, interviews, and prototyping iterations when following Design Thinking will give you a great sense of how much something is worth to your customer. Along the way, you'll also determine if your product will be a cost saver, a revenue maker, or both.

This last point is key for making sure your solution scales correctly with customer size and overall sales volume. Remember that cost-saving products have a much lower limit of value than revenue generating products, so it's important to control your costs. Don't build wonderful products that make for horrible business.

Identifying Value

One phrase I say several times a year is "It's only a good idea/product if someone will pay for it." Product and engineering management should be obsessed with delivering value to market, but how to do you identify value that's worth something to customers? How do you quantify it? I think determining the monetary worth of a given product increment is one of the hardest things product managers have to do, but unless everything you do is adding to your profit, even in some small way, it's detracting from your scalability.

In markets with open pricing, it's relatively easy to figure out market pricing. Everyone publishes for the world to see, you know your costs associated with those things, and figuring out how much something is worth to the customer might be as easy as reading an SEC filing or analyst report. On the other hand, in closed markets, it's much more of a challenge. Product pricing structures and business models vary so much from company to company that identifying a target price for a given feature is very difficult, if not impossible. So how do you do it?

Remember from Part 1: It's about the people. You must have direct, face to face conversations with the users, beneficiaries, and decision makers at target customers. These should be in person as much as possible. Even video calls lose too much information - off camera, non-verbal, and serendipitous encounters are very difficult to manage with remote meetings.

If your product is business-to-business (B2B), chances are good it's being subjected to financial analysis. Your customer will be making money and/or saving money with your product and it's imperative that you understand their business very well so you can have creative conversations about identifying valuable features and how much to charge for them. Even with business-to-consumer (B2C) products, you absolutely must be working directly with your customers through outreach like focus testing, beta programs, user conferences, and roadshows.

There's a lot more that goes into this process (see the Pragmatic Framework above), but this article would be way (way) too long if I talked about all the things that go into sensing, describing, and evaluating feature requirements, and that's just the first part of the cycle. Suffice it to say that getting the business model right is imperative, as is having skilled product managers who can wrangle the chaos. Without these two ingredients, the stuff described in the rest of this article is meaningless.

Prioritizing Implementation Order

If you know your customers well, chances are you'll have a number of compelling features competing for priority. Realistically, your development teams can't be working on very many things at the same time (this of course depends on team size and number of teams). So the next order of business is prioritizing when to deliver each increment of value to the market.

One method to do this is called weighted shortest job first (WSJF), which attempts to maximize the soonest delivery of the largest amount of value. Another method is RICE Scoring to help deliver the most impactful value first considering Reach, Impact, Confidence, and Effort. Regardless of how you prioritize your backlog, you should be striving to reduce waste (Lean; don't build things people don't want to pay for) and delight the customer (Design Thinking; build what satisfies their need) as soon as possible, then move on.

Another trick that can help balance these objectives is to deliver increments on each feature, even if they're less than what you know is the minimum needed. This is especially helpful whether you're using a sprint-based (e.g., Scrum) or continuous (e.g., Kanban) development process because it lets the teams deliver an increment to the consumer (or their proxy) to adjust course as needed and work on something else while they're waiting for that feedback. Using tight, incremental cycles to deliver value and determine the best next step is critical to maximizing your productivity as a development organization.

Delivering to the Market

So you've gathered requirements, you've determined the highest priority value, and you're ready to create and deliver it. How do you know when you're ready? How do you know when you're done?

One of the useful fictions promoted by Eric Ries in his book The Lean Startup is to pretend like you're an early-stage, venture-backed startup and, unless your next release convinces the VCs to invest more in your operation, you'll run out of money and close up shop. A lot of people don't like working under this premise, either because they work for a large, stable company or because they just don't want to think about being laid off, but I think it's a great illustration to help keep people focused on what's important about commercial software development: the money. If you perpetually slip an incremental release because "it's just not there yet," your customers will get frustrated and your benefactors will start wondering if their money is being well spent. So develop impactful value and deliver it in rapid, small increments. This is ideal for two reasons.

First, customers love new things. Even if they're not perfect, they can see progress. If they know you're going to be dropping a new release a few weeks later, they'll forgive a few minor bugs or missing features. This keeps your product fresh in their minds and gives them the endorphin hits every human craves as they get to unwrap each increment.

Of course, you can't drop half-baked bits into every production scenario, but having a beta environment to let them test drive in should always be available. In fact, supporting this sort of demo environment is useful for lots of activities like training, security sandboxes, and high-fidelity testing activities. This allows you to incrementally deliver to demo or beta installations where you show progress to stakeholders. This is crucial to running a Lean organization because you need to get feedback to make course corrections as soon and as lightweight as possible. Late, massive corrections can be fatal to a product or even the company making it - just don't do it.

Second, you need to get rapid feedback. John Boyd developed his OODA Loop in the 1950s based on his experience as a combat aviator. OODA stands for observe, orient, decide, act and is a useful construct for keeping yourself moving in the right direction, especially in highly dynamic environments. The first step is Observe, which you can only do if someone is using your product. With these observations, you can Orient yourself to actual reality you face, not your outdated perceptions. Then you Decide what to do next based on this updated view and Act upon it. The faster you can execute this cycle, the more accurately you'll address the actual market need and the sooner you'll capture the revenue.

When are you ready? As soon as you have something new to show and interact with your customer. This could be daily, should definitely be weekly, and in almost every scenario can be once or twice a month. Even if you can't interact with the actual customer more than once a month or so, there are useful proxies for them like product managers, service and support staff, and company executives. Definitely work with some friendly customers monthly or no less than quarterly to validate your solution.

When are you done? As soon as you determine there's no more worthwhile value to deliver. You must maximize your profit ("bang for your buck") with as little expense as possible. This allows your development organization to move on to the next high-worth bit of value, maximizing the profit on that as well. This is where backlog grooming and roadmap evaluations are very helpful. As soon as WSJF or RICE (or whatever you're using) move something to the top of the list, you must work on it. This is true even if it means you don't "finish" the last thing. When the process says you're done, you're done.

Summary

The most successful products are the ones that identify, prioritize, and deliver value worth the most money the fastest. Use an objective, quantitative approach to identifying value by working directly with your market. Also use an objective, quantitative approach to prioritizing what to do next and keep evaluating priorities on a rapid cadence (e.g., weekly). Deliver any increment that will help you reassess your market reality and change course as needed. All three of these stages must be done as quickly as possible - even in markets where you can't deliver to production on a daily or weekly basis, you can definitely push to a test environment this quickly. Doing these things will reduce the time it take to maximize your return on investment and converge with your market on the best solution for a need.

In the next and final part, I will discuss how to make your product have a long, healthy life. There's a delicate balance between over- and under-building, and either mistake can be terminal.

Next article: Part 4: Sustainability

Recommended Reading

The Goal by Eliyahu Goldratt (Amazon) [The original storybook for Theory of Constraints.]

The Lean Startup by Eric Ries (Amazon) [Measure, Improve, Profit (or Pivot).]

The Phoenix Project by Gene Kim et al. (Amazon) [An adaptation of The Goal for software and IT people.]

The Service Startup by Tenny Pinheiro (Amazon) [My introduction to Design Thinking.]

Turn the Ship Around by L. David Marquet (Amazon) [An excellent example of inverted leadership easily adapted to software engineering organizations.]

Wiring the Winning Organization by Gene Kim and Steve J. Spear (Amazon) [Probably the single best book I've ever read on technology management.]

Justin Wolf wrote his first line of code when he was about five years old. Since then, he's written hundreds of thousands of lines of code for consumer products in assembly language (Intel and Motorola), C, C++, C#, and other languages. In the mid 1990s, he began learning about computer networking while at Cisco Systems and spent a decade working on enterprise and residential networking products. He worked for about eight years at national laboratory on cybersecurity projects and then at a lab spin-out leading product development of a visual analytics platform fusing machine learning with human-in-the-loop analysis. Most recently, he led a large engineering team building massively distributed systems for battery energy storage systems (nearly 100,000 networked devices for the largest deployments). He lives in Southwest Washington state with his family (and pets) and enjoys sailing in the Pacific Northwest inland sea as often as possible.