40-50%. That’s the percentage of companies that manage the creation, iteration, testing and launch of new products with MS Office, Google Docs and other all-purpose documentation tools, according to research in Gartner’s “Market Guide for Software Requirements Definition and Management Solutions.”
Many other companies muddle through the best they can with clunky, kludgey, user-unfriendly legacy systems such as IBM DOORS.
Either way, when multiple teams are stuck with archaic tools that are a pain to use, Product Managers have a heck of a time keeping the people, the processes and the methodologies everyone must follow together.
Folks end up retreating to their silos of expertise, and that creates a bigger problem: When important product data is lost in emails or locked up in static documents, your teams fall out of sync, progress slows, important steps get overlooked and the product you’re responsible for becomes much more likely to fail.
As a Product Manager, you can’t afford to waste time on tools that bog down critical processes, because you’ve already got more than enough on your plate and on your mind:
Tall tasks:
Translating high-level strategic objectives into tactical implementation and making sure that everyone involved stays aligned.
Pressure points:
Connecting customer needs to product features.
Providing road map visibility and updates when things change.
Reconciling the opinions of stakeholders with concrete data and communicating critical details to the appropriate audiences.
Burning desires:
To be able to easily communicate strategy, vision, project status, blocks and needs in all directions.
With Jama, Product Managers can turn “Mission:Impossible” episodes into “MacGyver” epics.
How so? You’re able to…
Capture customer feedback, prioritize new features and plan releases faster.
Gain greater visibility into what is being built to ensure the product delivers what your customers, and the business plan, expect.
Communicate easily with the every individual on the project and program to get clarification and decisions made, regardless of location.
Read The Product Delivery Problem (hint: it’s not you) to learn more about the ways Jama can bring your team into alignment and up to speed.
Check out other ways Jama helps business and engineering teams get and stay aligned:
As product development and delivery has become increasingly complex, the role of product manager has become increasingly critical to product success. No one has to make or push through more decisions than product managers. With this heightened importance and visibility product management as a discipline comes a growing online community. Here are five product management sources to check out in order to stay up to speed on the biggest challenges and trend in product management.
Matt Khoury works in product for Thomson Reuters and publishes his perspective on product management via Medium. Matt has a knack for identifying what is great and challenging about being a product manager. His reads are engaging and bring some levity to the topics related to bringing products to market. He also actively curates content for the product management community on Twitter.
Follow Matt on Twitter at @MattAndersonUT. Matt is highly active in the product management community on Twitter. He curates great content about product management and shares interesting product news, and tips. Matt is also great at identifying new product management accounts to follow.
Rich Miranov is a writer, speaker and consultant of Agile product management. He regularly publishes his perspective on his blog where he examines current market trends and applies his expertise gained while working with startups as well as some of the largest technology companies. He can also be found on Twitter.
Ellen is a product manager and MBA candidate at Harvard Business School. She previously developed products for Kickstarter, and Microsoft. Ellen’s archives are rich with analysis of what it takes to be an effective PM and takeaways from her experience in various organizations as well as at HBS. You can also follow her on Twitter @ellenchisa.
The host and producer of the Global Product Management Talk podcast has conversations with some of the most interesting product people from Silicon Valley and beyond. The Global Product Management Talk podcast features fresh discussions around all things product management, from process, knowledge and forwarding product excellence. You can follow the conversation with #prodmgmttalk and follow Cindy on Twitter.
Know of some other great product management thought leaders? Share them in the comments below.
“There are so many moving objects when managing a product. You must be aware of them all (managing vendors, internal politics, management structure, development teams, testers, project managers, designers, architects, businesses, customers, etc.), and like a game of chess, you must be thinking ahead several moves in order to react (or not) properly. Nailed it. And, we would add, the processes you depend on to bring products to market must also adapt.
The many steps involved in building products—moving from product idea to release and, hopefully, to customer approval—have traditionally been relegated to product and engineering teams, at least until something goes wrong. Companies strive to update product delivery processes for the way business works today by involving stakeholders from multiple departments and including executive leaders. “Many hands make light work” goes the saying, the idea being that a collaborative, dedicated effort toward a shared goal should lead to desired results.
“Should” is the key word here. The challenges of integrating hardware and software, handling employees in multiple locations and different time zones, and dealing with immediate customer feedback, among many other things, adds a great deal of complexity to an already high-stress, fast-moving process. Companies recognize the business value collaboration can bring, but it’s much easier to advocate for than to organize and execute. Too often, collaboration devolves into design by committee.
Forrester Consulting conducted in-depth surveys with 150 senior business and IT professionals at enterprise organizations and found that a hefty one-third of companies release their products late. The top reason? A classic: Unclear or changing requirements. The surprising drag on reaching the finish line in time? Delayed decisions.
Executive leaders are the acknowledged decision-makers at the high level—giving the green light to build product X with Y specs for Z cost—but during the cycle of product development to release, no one has to make or push through more decisions than product managers. And at the rate 21st century companies conceive, build and release products, the time spent getting to market matters more than it ever has.
So while Matt Khoury astutely testifies to the many ways that product managers encounter problems on the path to release, we would add a note of caution for all companies who conceive and bring new innovations to market:
If you expect your employees to focus on outcomes, you need to adapt and you must also align teams; enable fast decisions, reuse and stakeholder involvement; iterate quickly and provide stakeholders and all participants with real-time context right up to the point of release.
The success of your product depends on it. Just ask your product manager.
The following guest post is the third in a series of four articles by innovation agitator Alberto Savoia (find the first here). Throughout his career as a serial entrepreneur and Google employee, Alberto has experienced great market successes–along with a few inevitable failures. In this series he’ll share his knowledge about why products fail and provide recommendations for beating the odds.
________________________________________________
In my previous two articles (found here and here) I introduced The Law of Market Failure which states: “Most new products will fail in the market, even if they are competently executed,” and identified failure in premise (i.e. building the wrong product to start with) as the most common, and hardest to recover from, reason for failure. In this article, we begin to look at how we can test a new product’s premise before we invest too much in it.
All new products begin with an idea. If all you have is the idea, however, the most you can do with it is to solicit opinions based on it; and if you do that, you are likely to run into a couple of problems that may seriously derail your decision-making process:
The Lost in Translation Problem: An idea is an abstraction–and a subjective one at that; it’s something that you imagine or picture in your head. The moment you try to communicate what you see in your mind’s eye to someone else you run into a challenging translation problem–especially if your idea is new and different from anything else they’ve seen. The way you imagine the new product and its uses may be completely different from the way they imagine it.
The Prediction Problem: Even if your audience’s abstract understanding of your idea is a close match to your original intention, people are notoriously bad at predicting whether they would actually want or like something they have not yet experienced, or if and how they would actually use it.
In my book, Pretotype It, I introduced the concept of Thoughtland, a fictional place where unrealized and untested new product ideas live. In Thoughtland, every idea can be a winner or a loser–depending on whom you ask … and how you ask it. This can lead to two dangerous outcomes:
False Positive: People like your idea, they think they understand it and can see themselves using it. They give you thumbs-up and tell you to go ahead: “Go for it! If you build it, we’ll definitely buy it and use it.” Fueled by such positive feedback you proceed to implement the idea. But after you launch it, all that enthusiasm and all those plans to buy and use your product are nowhere to be seen.
False Negative: People just don’t get your idea, or it makes no sense to them. They don’t see what you see. When you talk about your vision, they think you are hallucinating: “Have random people follow you as you write 140 character blurbs? You’ve got to be kidding!” As a result, you drop any plans of implementing your idea and move on. And a few months later another company launches a very similar product to great success.
False positives can lead you to believe that your idea is immune to The Law of Market Failure, so you invest too much too soon in a new product that will eventually flop. False negatives, on the other hand, can scare you away from giving your idea a chance, and you end up prematurely scrapping the next Twitter, or Google, or Tesla.
To minimize your chances of getting false positives or negatives you need to collect something more substantial and objective than opinions–especially when the people who give you those opinions have no skin in the game. And the only way to do that is to transport your idea from Thoughtland to a more concrete environment–let’s call it Actionland.
In Thoughtland you use abstract ideas to ask hypothetical questions and collect opinions.
Thoughtland: Ideas -> Questions -> Opinions
In Actionland you use artifacts to prompt actions and collect data.
Actionland: Artifacts -> Actions -> Data
Let’s say, for example, that you have an idea for a computer monitor stand with sensors and motors that automatically moves and adjusts for optimum ergonomics. Let’s call it The Last Stand–as in: “You can now last longer working at your computer.”
If all you have is the idea and, perhaps, a drawing, you are stuck in Thoughtland. You can go around your office, explain the idea to your colleagues and ask them questions such as: “What do you think of this?”, “How much would you pay for it?” You can reach out to other companies and talk to HR departments: “Would you consider buying this for your staff?” “How many would you order?” That’s a lot of hypothetical questions and subjective answers (with no skin in the game)–not a lot to go on.
Of course, you might learn a few useful things in the process. For example, that most people would not use their own money on The Last Stand, but would be happy to try it–if the company pays for it. Before you make an expensive new product decision based on a flimsy combination of ideas, questions and opinions, however, remember The Law of Market Failure.
As I’ve mentioned in my first article: “In criminal law, a person is presumed innocent until proven guilty. When it comes to market law, we should presume a potential new product to be a failure–at least until we’ve collected enough objective evidence to make us believe otherwise.”
And to collect that objective evidence, you need to move from Thoughtland to Actionland.
You can do that by building a proper prototype of The Last Stand (i.e., an actual stand with sensors and motors–and all the software to run it.) But such a prototype will be costly and will take weeks/months to create.
On top of that, working prototypes are great for determining the feasibility of a new product (Can we build it? Will it work?) but are not sufficient for determining if there is a viable market for it.
Wouldn’t it be wise to objectively test and gauge the potential market for The Last Stand–at least a bit–before making a major investment in prototyping it? Are there other artifacts we use can to collect market data that are simpler, cheaper and quicker to build than a prototype? Yes, between abstract ideas and proper prototypes there are pretotypes:
Pretotype, noun: An artifact used to test hypotheses and collect data about the market appeal and actual usage of a potential new product objectively and with a minimal investment of time and money.
Pretotypes help you to “make sure that you are building The Right It before you build It right.”
In the next and final article in this series, Pretotype It, I continue my discussion of pretotypes and show you how simple pretotypes can quickly take you from Thoughtland to Actionland and be used to collect valuable market data. Please share your thoughts about decision-making in building products in the comments below.
Read the fourth and final article in the series: Pretotype It.
About Alberto Savoia
As a serial entrepreneur and an early Google employee (where he led the development and launch of Google’s AdWords), Alberto Savoia has experienced great market successes–along with a few inevitable failures. Most entrepreneurs and innovators respond to failure by licking their wounds and moving on to their next idea. But Alberto decided to first deal with the sting of failure by stinging back. Between 2008 and 2011, while still at Google, Alberto became a serious student of failure in new and innovative products. After reading dozens of studies and analyzing hundreds of new products, he was able to identify the main cause for why most new products fail in the market, and developed a set of techniques, which he called Pretotyping, to minimize such failures.
The concept, techniques, tools and metrics of pretotyping were an instant hit within Google; and soon Alberto found himself teaching pretotyping at Stanford University and at many companies, from startups to Fortune 500. His handbook “Pretotype It–Make sure you are building The Right It before you build It right” has been translated in many languages and has become an invaluable guide for thousands of innovators and entrepreneurs world-wide. Alberto’s work on innovation has been recognized with numerous awards, including The Wall Street Journal Innovator Award. Learn more about Alberto on his website and follow him on Twitter @Pretotyping.
[raw]
To read the updated version of this article, visit www.jamasoftware.com/blog/defining-project-scope-context-use-case-diagrams/.
[/raw]
Every software team talks about project scope and team members often complain about unending scope creep. Unfortunately, the software industry lacks uniform definitions of these terms, and the requirements literature is short on clear guidance regarding how to even represent scope. I confront scope head-on in this series of three articles, adapted from my book More about Software Requirements (Microsoft Press, 2006). I’ll present some definitions, describe four techniques for defining project scope, and offer some tips for managing scope creep.
Vision and Scope
I regard the vision and scope document is a key software project deliverable. You can find a suggested template for this document at http://www.processimpact.com/goodies.shtml. Other terms for this type of guiding document are a project charter, market (or marketing) requirements document, and business case. You don’t necessarily need a standalone vision and scope document for a small project. Any project of any size, though, will benefit from such strategic guidance, even if it’s just a paragraph or two at the beginning of the software requirements specification.
Both the vision and the scope are components of the project’s business requirements. I think in terms of the product vision and the project scope. I define the product vision as: “A long-term strategic concept of the ultimate purpose and form of a new system.” The product vision could also describe the product’s positioning among its competition and in its market or operating environment. Chapter 5 of my book Software Requirements, 2nd Edition describes how to write a concise vision statement using a simple keyword template.
I’ll define project scope as: “The portion of the ultimate product vision that the current project or iteration will address. The scope draws the boundary between what’s in and what’s out for the project.” The second part of the project scope definition is most important. The scope identifies what the product is and is not, what it will and won’t do, what it will and won’t contain.
A well-defined scope sets expectations among the project stakeholders. It identifies the external interfaces between the system and the rest of the world. The scope definition helps the project manager assess the resources needed to implement the project and make realistic commitments. In essence, the scope statement defines the boundary of the project manager’s responsibilities.
Your scope definition also should include a list of specific limitations or exclusions—what’s out. Obviously, you can’t list everything that’s out of scope because that would include every detail in the universe except for the tiny sliver that is in scope for your project. Instead, the limitations should identify capabilities that a reader might expect to be included in the project but which are not included. I know of a project to build a Web site for a national sports team that included the following exclusions for the initial release:
There will be no virtual or fantasy games via the Web.
There will be no ticketing facilities on the site.
There will be no betting facilities available.
The demographic details for newsletters will not be collected.
Message boards are out of scope for phase 1.
Some stakeholders involved with this project might have expected these capabilities to be included. Itemizing them as exclusions makes it clear that they won’t be. This is a form of expectation management, an important contributor to project success.
The rest of this article describes two techniques I’ve found useful for depicting project scope, the context diagram and the use case diagram. In part 2 of the series, I’ll describe two additional techniques, feature levels and system events.
Context Diagram
The venerable context diagram dates from the structured analysis revolution of the 1970s. Despite its antiquity, the context diagram remains a useful way to depict the environment in which a software system exists. Figure 1 illustrates a partial context diagram for a hypothetical corporate cafeteria ordering system. The context diagram shows the name of the system or product of interest in a circle. The circumference of the circle represents the system boundary. Rectangles outside the circle represent external entities, also called terminators. External entities could be user classes, actors, organizations, other software systems to which this one connects, or hardware devices that interface to the system.
The interfaces between the system and these external entities are shown with labeled arrows, called flows. If the “system” is strictly an electronic system involving software and perhaps hardware components, flows will represent data or control signals. However, if the “system” includes both a software application and manual operations, flows could also represent the movement of physical objects. Two-headed flows indicate update operations involving the data object on the flow.
The context diagram depicts the project scope at a high level of abstraction. This diagram deliberately reveals nothing about the system internals: no information about functionality, architecture, or look-and-feel. Nor does it explicitly identify which features or functionality are in scope and which are not. The functional behavior of the system is merely implied by the labeled flows that connect the system to the external entities. Even the flows are labeled at a high level of abstraction, just to keep the diagram’s complexity manageable. The business analyst can decompose these data flows into individual data elements in the project’s data dictionary or data model. Corresponding data inputs and outputs imply the types of operations the system will perform, but these aren’t shown explicitly in the context diagram.
Despite the limited view that the high level of abstraction imposes, the context diagram is a helpful representation of scope. It serves as a tool to help the project stakeholders communicate about what lies outside the system boundary. A BA in a requirements class I once taught showed me a context diagram for her current project. She had shown this diagram to the project manager. The manager had pointed out that one of the external entities shown on the context diagram, another information system, was now going to be part of the new system. With respect to Figure 1, this would be like moving the Payroll System inside the project circle. That is, the scope of the project just got larger than the BA expected. She had expected that external system to be someone else’s responsibility, but now it was her problem.
Use Case Diagram
Use cases are a powerful technique for exploring user requirements. The Unified Modeling Language (UML) includes a use case diagram notation. Figure 2 shows a partial use case diagram for our cafeteria ordering system. The rectangular box represents the system boundary, analogous to the circle in a context diagram. The stick figures outside the box representactors, entities that reside outside the system’s context but interact with the system in some way. The actors correspond approximately (exactly, in this example) to the external entities shown in rectangles on the context diagram.
Unlike the context diagram, the use case diagram does provide some visibility into the system. Each oval inside the system boundary box represents a use case. The use case diagram shows the interactions of the system with its users and some connections between internal system operations, albeit at a high level of abstraction.
The arrows on the use case diagram indicate which actors participate in each use case. In Figure 2, the arrow from the Patron to the oval labeled “Submit Feedback” means that the patron actor can initiate the Submit Feedback use case. The arrow from Submit Feedback to the Menu Manager actor indicates that the Menu Manager participates somehow in the execution of Submit Feedback. Arrows on the use case diagram do not indicate data flows as they do on the context diagram. Some analysts simply draw lines instead of arrows on the use case diagram to avoid any confusion with data flow. In addition to showing these connections to external actors, a use case diagram could depict logical relationships and dependencies between use cases.
The use case diagram provides a richer scope representation than the context diagram because it provides a high-level look at the system’s capabilities, not just at its external interfaces. There is a practical limitation, though. Any sizeable software system will have dozens of use cases, with many connections among them and between use cases and actors. Attempting to show all those objects inside a single system boundary box quickly becomes unwieldy. Therefore, the analyst needs to model groups of related use cases as packages or to create multiple use case diagrams.
Many analysts have found the context diagram and use case diagram to be helpful ways to represent and communicate a shared understanding of a project’s scope. In Part 2 of this series, I’ll describe two other techniques for defining scope, feature levels and system events.
