Process This: Product Requirements Planning

 

A colleague recently lamented the challenge of a security-related development effort that presumably met the product requirements spec, yet failed upon audit. Product Engineering would maintain they’re just driven by the PRD, and the development will be fast and complete – just as soon as all requirements are solidified and they can pull the trigger. But it’s not uncommon for requirements for any sophisticated system (security related or not) to be incomplete, at least until the later stages of a development program. Things are overlooked, new issues arise, and even the existing requirements are sometimes found to be ambiguous or fuzzy. The fix is to be found in the dev process, not with the management or a specific department or function. The higher levels see the world with a broader brush, whereas the missed requirements are usually in the details – the specific design choices, uncommon use cases, etc.

I’m not a fan of heavyweight process management, but the following structure can provide gentle discipline to product development and lends itself to continuous improvement.

1. Product requirements document joint review

Sending a written document is insufficient; each product requirement should be jointly reviewed by the product/ business owner, the dev manager(s) and product architect to weed out ambiguous language, surface any questions or issues and technically validate the request.

2. Architecture review and design reviews

Although these reviews play mostly to the engineering audience, it helps to have the implementation discussed interactively. In hearing the design explained, the product owners and the developers will be prompted to ask questions, further crystallizing the product requirements and ironing out design choices. In particular, having each developer describe her or his design ensures nothing got lost since the requirement was first scoped and accepted. Furthermore, the discussion might reflect trends or future requirements that should be anticipated in current design decisions.

3. Preservation and extension of requirements documents

As nuances are identified during these reviews and during the development process itself, the product or program manager must have the discipline to capture these important details and keep the product requirements document and other program artifacts current so the organization learns and future programs benefit. Ideally, a program manager fills these gaps between organizational functions and orchestrates the process; but the focus should be less on the schedule and more on the quality of the release.

4.  Collaborative ownership

The product team, consisting of business owner, product manager and engineering, must acknowledge and embrace the dynamic nature of the beast and assume shared responsibility for meeting the business requirements. Each player has an equal chance to mess things up by focusing too narrowly. Each player also has a chance to think broadly about the problem, and anticipate issues that nobody thought to write into the spec. While it may seem reasonable that engineering simply needs to meet a given set of requirements, in reality the requirements are complex and evolving, and a collaborative approach is essential. Frequent informal communication across the team helps minimize surprises.

In a fast-growth organization with new engineers and new managers constantly entering the picture, these disciplines help normalize the planning and prevent previous ‘learnings’ from being lost to attrition or organizational change. The process is never perfect, but process improvement can always be expected.

 

 

Share This:

Three simple steps to improve IT customer experience

From Palo Alto’s BigPanda comes a recent IT management report, The State of Monitoring, presenting survey results of 1500 IT professionals from various industries. Not surprisingly, the large majority of respondents (80%) listed their top operational and monitoring challenges to be the usual corporate suspects: budget, resources (staff), schedules, and responsiveness to service disruptions.

Also nestled in the list of the top five monitoring concerns, noted by 78% of respondents:  “Reducing alert noise from the organization’s monitoring tools.”  This happens to be a key business focus of BigPanda, but it also highlights a problem — and an opportunity — for equipment vendors striving to better meet customer needs.

Development Phase Review

IT product developers, working with their customer support counterparts, can greatly improve the customer experience by inserting three simple review steps into the release development cycle:

  • Jointly scrub the system message catalog and SNMP MIB during the development phase. Is each message informative and valuable to the user, or does it state a vague internal condition of unknown significance?
  • The severity and frequency of each alert or message should be assessed using a consistent rubric. Is the operational impact (or risk) of a problem correctly conveyed? Is terminology consistently applied, particularly compared to the UI? Can multiple related log notices be consolidated, or prioritized and selectively muted?
  • For important alerts that do get passed on to the customer, ensure they are specific and actionable so the condition can be corrected without delay.

For UI developers, it is equally important to have a solid alert review process underneath. It is pointless to allow a steady stream of alerts and notices that push important messages from view in the UI. High impact issues should either remain visible or be easily recalled. But they could also be consolidated to efficiently account for recurring unacknowledged alerts.

Sooner is Better

One consequence of severe over-reporting of system messages is that customers sometimes have little choice but to ignore them all. Secondly, alerts and notices poorly done can become ‘case generators’ for the vendor’s support organization. With a large installed base, the cost becomes problematic. The product development team can help minimize such calls, and the sooner the better: Even when fixed, it’s not uncommon for OS updates to take many months to permeate the installed base.

Incident management tools such as Big Panda‘s help IT administrators deal with an ever-increasing volume of alerts received from their data centers, particularly by providing multi-vendor support and event correlation in a single tool. But it’s in the equipment manufacturers’ own interest to step into their customers’ shoes and recognize that there is competitive advantage to improving their products’ alert behavior.  A streamlined and more actionable alert system can reduce calls to Support, improving customer satisfaction and reducing support costs. With better-quality data input, analytic monitoring tools such as BigPanda’s further enhance the sysadmin’s ability to cut through noise and distraction in day-to-day IT management and focus on the best service delivery possible.

 

Share This:

Faster, Better Development Results with ‘Little Data’ Analytics

Engineering metrics and product dataFor all the energy going into Big Data and artificial intelligence, much remains to be said for “little data” and conventional analytics.
A lot of companies can substantially improve their product development, customer support and quality simply by investing in analytics to leverage the product and customer data they’re already collecting.  

Data-driven management

Good product development practices and backend processes enable data-driven management for faster, more predictable development cycles and more timely, effective customer support.  It’s common practice to characterize and monitor the installed base log data to inform product management of customer preferences, adoption rates and priorities for new features.  But deeper configuration tracking allows prompt, targeted customer support actions when issues arise.   Integration of customer case information with CRM data exposes potential obstacles to new sales campaigns in major accounts.  Combining source code changeset information with defect tracking exposes missed integrations before they become regressions in the field.

The key is often in integrating data from independent systems, a sort of one-plus-one-makes-three approach.  With hundreds of deployed products, multiple branches of product code, and thousands of bugs (tasks) driving development efforts, automated tools are essential to gleaning these nuggets that drive decision making.

Such engineering management tools help prevent mistakes and improve predictability during product development, and they expose what’s important without relying on individual expertise.  In a fast-growth organization with new engineers and new managers constantly entering the picture, the tools help normalize the planning and management processes and enable the team to spend more energy on getting the product to market.  

Enabling growth

I’ve seen data analytics pay dividends to young and growing organizations, without the complexity of big data infrastructure that is demanded of larger scale analytics challenges.  By investing early in this under-the-covers capability, faster and better decisions will lead to faster growth and higher customer satisfaction overall.  You still need analytics infrastructure and database specialists to build a robust system with dependable performance.  But there’s much untapped value at this simpler end of the analytics spectrum.  As the organization grows, big data methods will likely find their place, and the mindset and processes will be in place to fully exploit them.

 

Share This: