Agile Product Strategy, Marketing, ProductCamp and more.
RT @celia: (via @StephenFleming) Steve Blank: "The golden age of Silicon valley is over..." m.theatlantic.com/business/archi… @sgblank
Agile
The business needs product management to be agile, too.
162 days
Let’s not kid ourselves, when it comes to building and marketing business solutions, we’re not building software as part of a science project–we’re in this for the ROI. The business doesn’t care whether you’re agile or waterfall or something we haven’t thought of yet, as long as that return is delivered as promised.
That ROI can only be delivered by fulfilling the primary purpose of product management: creating a compelling solution to a pervasive market problem that buyers are willing to pay to solve. Lean Startup refers to “product-market fit,” which ensures that not only do you have a market problem buyers will pay to solve, but that the solution you are delivering is the best one possible. That fit isn’t present until your users can’t live without the product. Such a fit can only be achieved by imagining a solution in tandem with a designer and a technologist, and then iterating based upon real customer input–or, as it were, being Agile. Agility is in product management DNA, and by far is NOT simply a more adaptive project management framework.
B2B products have traditionally focused less on design than B2C, but I firmly believe the consumer’s expectations have been raised so high by revolutionary User Experience (UX) in products like the iPhone that startups in B2B will overtake established companies if they don’t invest more in UX. Enterprise software can’t continue to underwhelm–so product managers can’t hand design over to engineering and avoid being involved in design.
Product managers are traditionally owners of the problem space, but they need to play an active role in the solution space also to achieve optimal product-market fit. By ensuring thoughtful, user-centered design, the solution can be as good as the definition of the problem. Agility is a product development approach that helps get to product-market fit faster, which is what Greg Cohen and others call Lean Product Management.
It is not enough for product managers to throw a PRD or MRD over the wall to engineering after passing the relevant gate, and for engineering to begin developing the product in two-week iterations. That’s not agile! The business needs product management to be agile, too. If your engineering team is iterating but you haven’t validated that the solution is the right one, why are you still building something you haven’t confirmed the market will purchase?
Product Management should be bringing new market insights on a regular basis both before and during construction, and Product Management leaders should track how frequently backlogs change. Markets change; customer visits reveal new insights. If a backlog is too static, the product manager isn’t getting enough input! Certainly the top of the backlog, the most important items, should be relatively solid, but anything below them is fair game for perpetual re-evaluation. And it’s the product manager’s responsibility to continually re-evaluate–or in scrum parlance, groom the backlog.
Product managers should think Lean Startup: Work towards MVP using prototypes [Build], get user feedback [Measure], and adapt [Learn] to achieve optimal product-market fit. Once released, each subsequent major enhancement should go through the same cycle–prototype, get real user feedback, finalize. Don’t just play product owner, sit in the scrum room and shepherd your static backlog through the development process. Be agile!
Lean Startup: Build - Measure - Learn
Interview: Rich Mironov
2159 days
Last week, I had the pleasure of interviewing Rich Mironov. Rich is an accomplished product executive and startup veteran who’s spent significant time evangelizing agile product management. Rich also founded the very first ProductCamp in Silicon Valley, and wrote The Art of Product Management based on content from his Product Bytes blog.
Rich and I spent about half an hour discussing three primary topics: ProductCamp, Agile Product Management, and the Product Management career path. Some of the specific discussions included:
- How ProductCamps can increase awareness among senior and executive level product management.
- How product managers can help engineering organizations to understand everything that product managers do outside of engineering to help ensure the success of a product.
- What are the options for a product manager to advance in the field.
Rich provides great insights in a relaxed, disarming style. Rich can be reached at his blog (http://www.mironov.com) or by email at rich@mironov.com.
Enjoy!
Audio clip: Adobe Flash Player (version 9 or above) is required to play this audio clip. Download the latest version here. You also need to have JavaScript enabled in your browser.
Shared audio file for those who need to access it outside the blog, via Box.net
Product Management and Solution Design
3185 days
A valuable reminder was posted by Martin at Mind the Product today about focusing product management attention on the problem space, rather than the solution space:
At a ProductTank last year one question from the audience made me want to jump up on stage and answer it myself – “where’s the innovation and creativity go if product managers are defining all the products?”. Stop, I wanted to shout, you’re doing it wrong….Product managers should not focus on designing solutions – they should focus on defining and prioritising problems.
Product managers generate value for their companies by finding market problems that potential customers will pay to solve, and then leading the process of finding a feasible and compelling solution.
This does not mean the product manager designs the solution, in fact, many are not trained to do so. That distinction is drawn clearly in a post from 2005 by one of my favorite product management writers, Roger Cauvin:
A product manager determines the requirements for a product, but not its design. Thus a product manager specifies what a product should do (functional requirements). She also places constraints on the product’s behavior (nonfunctional requirements), such as how easy to use it should be. But placing constraints on a product’s behavior does not mean specifying the product’s design.
A product manager is uniquely qualified to learn what the market demands and translate this knowledge into product requirements. But only an ergonomist or user interface expert is qualified to design a product that satisfies these requirements. How many product managers are trained in user interface design?
It is far different to find–and then define–a market problem than it is to figure out the best way to solve it. Many are guilty of confusing the two.
Where it concerns product design, I subscribe to the Marty Cagan “Product Discovery” model for designing winning products. In Marty’s model, the product manager brings an understanding of market problems to the table, and collaborates with the other two key members of the product discovery team–the user experience designer and the lead developer–to discover the right solution. That solution is discovered by brainstorming, generating a high fidelity prototype, getting real user feedback and then brainstorming again to iterate on the prototype, repeatedly until an optimal solution is “discovered.”
The key point relevant to Martin’s article is that the product manager isn’t designing the solution–the product manager leads a team of three to design the best solution. Marty explains in an insightful post on designing winning products in a large organization:
The key for every product discovery effort is to identify the three key people – the product manager, the user experience lead, and the product development lead. These are the three minds that must collaborate closely to solve problems in new and useful ways.
I’ve seen teams repeatedly in which user experience and product management collaborate on their own to create a design, and then find out too late that the design either (1) just won’t work, or (2) will be too costly to deliver to market in an acceptable time frame. The design isn’t the purview of the product manager individually, nor is it that of the lead developer. Product design is a collaborative effort.
Here’s Marty discussing, as he calls it, the Product Discovery Team:
Should the product manager be product owner for new product development in Scrum?
2243 days
In an earlier post, I wrote that the model of having a strategic product manager partner with a tactical scrum-team-immersed product owner delivers business value best under limited conditions. As this will be one of the most controversial topics during my talk tomorrow on #ProdMgmtTalk, I want to reiterate my rationale here in a more verbose form.
The two conditions I listed are:
1) The product is marketed to a segment of customers, not just one.
2) The product is already released to market, and is thus beyond v1.0.
The "Product Owner" without Product Management responsibility is really a Backlog Manager.
Delivering business value in this context means developing a product that meets the needs of the market, and fulfills the product vision that capitalizes on market opportunity. In the stage-gate days, product managers would “capture” that vision in MRDs and PRDs and toss them over the wall, and then be frustrated that the product which came out the other end did not deliver. By providing periodic visibility of work product, Agile processes are often implemented to address this long-observed waterfall limitation.
I suggested that in other conditions–specifically mass market products during intitial development–companies may wish to consider having the product manager serve as product owner, in order that the person with the best knowledge of the market and problem space is guiding the product’s development. This blog is an attempt to clarify some of the arguments supporting this position.
My suggestion generates much contention among ISV product management purists. In agile development in general–and scrum, specifically–heavy demands are placed on the product owner. Chief among these demands is the regular management of the backlog by breaking down high priority user stories, and the need for consistent availability by the development team. Product owner availability ensures the development team has the resource necessary to explain the rationale for features, and to work with team to validate the best way to implement each user story.
Product managers are members of the business, not of the technology team. They are responsible for identifying market problems that people will pay to solve, which can most effectively be done by spending time with customer representatives and studying the market rather than by spending time in the scrum room. Product managers must interface with the rest of the business in order to coordinate the surrounding roles: creating training guides, helping marketing with positioning and messaging, sales support, etc. Product managers are often responsible for more than one product, leading their focus to be strategic rather than tactical.
Clearly, these two roles cannot be the same person! Or can they? I believe there’s a case for these two roles being occupied by the same person during the initial release of a product.
When companies implement scrum, common guidance states that product management needs to staff up by adding a product owner to the ranks to support the product manager. I believe in some company cultures, this remains the best option. I believe, however, that an alternative model should be considered: While release 1 of a brand new product is under construction, the product manager works only on that product and serves as product owner on the scrum team personally.
This proposal implies a redistribution of responsibility among the product management team — someone else must manage the product manager’s other products to allow the product manager singular focus on the new development. Many teams won’t be able or willing to make this sacrifice, for one or more of many reasons including (1) there aren’t market experts to replace the product manager on the other products, or (2) the cost of bringing in a product owner on the new product is lower. However, there is a primary disadvantage to keeping the product manager on multiple products including the release-1 effort: Lack of Focus.
A Product Owner is often brought in to partner with product management as part of the “product owner team” or “product discovery team“. This arrangement usually involves the Product Owner meeting regularly to ensure day-to-day execution of the product manager’s vision, while the product manager meets with customers, develops pricing, champions the product, and manages the other products in the product manager’s portfolio. Conversely, the Product Owner may not have the luxury of all the customer visits, market research and competitive research the Product Manager used to develop the business plan and the product vision.
This lack of focus is the problem.
The Product Owner is encouraged to be in the scrum room during a majority of his time, to help with all the day-to-day decisions that go into building the right product. In this arrangement, this means that the person with the deepest direct knowledge of the market and the problems the product is intended to solve…isn’t. When called upon to explain rationale and help with interaction design, or any of the other elements about which the product owner is asked to participate, the product owner must rely upon limited customer interaction and second-hand understanding obtained through others. This leads to weaker positions in discussions with developers, and may have unintended consequences that manifest in the design of the app. These consequences may not be related to something the product owner says–in fact, it may be because of something the product owner doesn’t say.
To implement this, it may require a bit more sequential thinking than scrum purists would support:
- The product manager builds out market justification and designs the solution (with the lead designer) before starting construction.
- The product manager allocates a majority of time during construction to development team support.
- During buildout, the product manager strategically allocates mid-sprint time to customer visits and product reviews. This time after working through the current sprint user stories and before the race to capture points at the end, is often a quiet time for the product owner. Note in a two week sprint, this may be roughly 4-5 days of a 10 day sprint.
This last point illustrates why this requires allocation of the product manager to the new product exclusively — there isn’t leftover time in this model to work on other products. When exclusivity is not an option, the product manager works with the product owner to ensure the solution addresses the market problems. As I’ve mentioned, this separation is risky.
One way to counter the risk is to bring the product manager in when anything important comes up, however, it’s very difficult to determine which instance of the “butterfly effect” may require the presence of the product manager. Often the product manager is unavailable, and delaying an answer to arrange a conversation may interfere with the team’s velocity.
Another option is to have the product owner conduct the competitive research and customer interviews to ensure they are market experts as well. But then, isn’t that blurring the lines and having the product owner serve as product manager? And if they’re showing prototypes of the product to customers throughout the construction process, are they as available as the development team needs them to be? Perhaps teaming with a product marketing manager can offload some of the outbound marketing and sales responsibilities, but there will still need to be someone with product and market knowledge guiding the sales of the product and its positioning in the market. And the product owner in this case will be doing a lot of the inbound marketing that is the core of product management.
Are there other approaches? Can these challenges be resolved by having another member of the design team–the user experience specialist–available to the team as well?
Please share your thoughts in the comments.
ProductCamp is over…on to #ProdMgmtTalk!
0246 days
Another fantastic ProductCamp is in the books–that’s #5 for Atlanta–and the planning team is busy working on what’s coming up next. The two at top-of-mind are listed here; however, please follow us on Twitter to make sure you don’t miss anything!
- - Please complete the ProductCamp 5 Wrap-Up Survey
- - Please post your ProductCamp 5 Content on SlideShare
We’re giving ourselves about 10 days before we start thinking about the next event, possibly a happy hour in the Fall. Some of us are already making preliminary plans to visit our neighbors in Nashville for their first ProductCamp ever on November 12. Perhaps you might want to join us?
With a nod toward the session I led at ProductCamp this past Saturday, I will be the guest of honor on the next #ProdMgmtTalkTwitter chat which occurs at 7pm Eastern on Mondays. This talk is hosted by Cindy Solomon and will be co-hosted by Roger Cauvin, who I had the pleasure of meeting during my time in Austin. I find Roger’s blog to be one of the best-written on the topic of product management, with particular emphasis on agile approaches to the subject, and I look forward to his participation in the talk. Cindy and I have spoken about focusing the topic of our talk around backlog management during development of the initial release of a product, as that is an area I’ve uncovered (and..caused!) some controversy. Hope you can join us next Monday.
Where “Product Owner” as “Backlog Manager” fits best
9302 days
In a recent post, Saeed Khan wrote that the Scrum role of “Product Owner” should be redefined to describe a more accurate set of responsibilities: “Backlog Manager.”
Saeed’s argument is that the Product Owner role is really a project-specific role implemented within the Agile movement as a solution to inaccessible product management. Saeed observes that more and more product management responsibility is bleeding into the Product Owner role, which is intended to be the funnel of business input to the development team. This conflicts with the primary responsibility of the role, which is to provide a set of fully groomed user stories representing the next most important features that should be built, and to be available throughout the sprint to answer questions.
After considering this since Saeed’s post, and based on my own experiences on four scrum projects, I’ve come here to propose that there is a “best case” condition under which this arrangement makes sense, and several others under which it doesn’t quite work.
The Case where a Backlog Manager makes sense
The first thing to remember is that Scrum has infiltrated software development from the custom software world. When building custom software, there is a single customer whose wants and needs are primary — and time has shown that having a representative of the customer in the war room at all times can help the development team deliver something meeting the customer’s needs in an efficient manner. In this context, because the Product Owner is often an employee of the client who has broad and wide domain knowledge, it makes sense that a single person bears all the responsibility of the product–and it makes sense that a single person can deliver it! This set of conditions does not demand that we separate the tactical “product owner” responsibilities from the business “product management” responsibilities because they are so intricately tied together–and the product is being built for one customer!
When we look at independent software vendors, however, we encounter the difficulties with balancing the strategic and tactical that many Product Managers express. A product manager must synthesize the needs of a market segment to deliver a compelling offering, and successfully prepare it to be marketed to that segment. If the Product Manager (title) occupies the role of Product Owner, spending much of his/her time on tactical items for upcoming sprints, the pattern seems to be that access to the market is less common.
It is at this point that the notion of “Time” becomes important. I believe the tactial responsibilities of backlog management can be offloaded by a Product Manager to someone filling the role of Product Owner (a Technical Product Manager, a Business Analyst, etc) under one condition: After a product’s initial release to the market.
In my ideal process, before starting construction of a new product, the Product Manager will spend significant time in the market understanding the problem space, developing business case and initial requirements, to the degree that he/she is prepared to spend a number of months focusing on development. It is only with this focus that a clear vision of the product can be brought to the team and shepherded to completion.
Backlog management will take a great deal of time, but the product manager’s command of the entire product is essential to having it built correctly. With a competent team, the Product Manager serving as Product Owner can still find time to make periodic visits to customers to get feedback on early builds and gain the input needed to “inspect and adapt.” But if this feedback only reaches the team second hand, the risk to the cohesiveness of the product is too high.
After version 1.0 of a new product, when the product is in customers’ hands and is being considered by prospects, the vision, business case and purpose of the product is already established. Now that the product is built, the product manager is looking for additional market segments and business opportunities, finding the problems which adding solutions into the product would open up new markets. Additional important and complex features may be added, but the basic nature of the product is already set. Given this stability, the profitability of this product can be managed by one individual, while the tactical implementation of new features can be efficiently offloaded to another. This is the case where separating responsibility between a Product Manager and a Product Owner makes sense.
These three statements summarize my position:
- For custom software vendors, there really is a single “product owner” that fits with Scrum orthodoxy. This “Product Owner” is a representative of the customer.
- For ISVs developing version 1 of an off the shelf product, a single person should own the business and technical sides of the product. That single person learns the market and helps build the right solution.
- For ISVs developing later releases of an off the shelf product, the backlog management responsibilities can be split from P&L / business responsibilities. The boundaries are set, and a “backlog manager” or “technical product manager” can work with the Product Manager to understand the goals of the next release and execute, while the product manager coordinates sales, channels, support, and other arms of the company.
Special Note: During the development of a Version 1.0 release, because it makes sense to have the single person with best understanding of the business case overseeing the development effort, in most cases it does NOT make sense to have one person overseeing the buildout of more than one product! The workload to understand business needs, positioning, usability needs, requirements and user stories, and implementation details is too great to split that person’s time into multiple threads. I can confirm this from personal experience!
ProdMgmtTalk: Product Manager vs. Product Owner
8424 days
Today’s Global Product Management Talk, a weekly realtime Twitter conversation among product management professionals, covered the topic “To Agile or Waterfall…Does it Matter?” featured John Mansour, CEO of Agile Bench. As an agile product manager, I looked forward to this conversation despite that its timing at 6pm Eastern prevented me from participating realtime. The first posted question was “Product Manager, Agile Product Owner, What’s the Difference?” Since this is near and dear to my heart, I’ve composed my response here.
Some of the comments from the host that I found especially helpful included:
- agilebench: “Product Manager and Product Owner are two roles, sometimes occupied by the same person.”
- agilebench – PMs – outward (customer) facing. Channel, brand, price, the whole product. Strategic. POs – inward (project) facing. delivery, detail focused. Tactical.
The Problem: One huge problem is when one person tries to do both roles. From personal experience, I can confirm that especially with large-scope products in multi-national corporations with products in multiple silos, it’s practically and effectively impossible. Brainmates summarized the problem I experienced: “Market focus suffers, because it’s easier to work on tactical development activities.” In companies I’ve been exposed to, it was not only “easier,” but there were so many fires that there was really no choice. Because of the product’s complexity and the complexity of the organization (not to mention infighting and territorial-ism) there simply wasn’t enough time to participate in user story level design discussions, groom the backlog, coordinate sales and support, and simultaneously monitor the competition, research trends and pricing, and the other activities a business leader in the company should perform.
The Team Approach: As an alternative, agilebench suggested “can you find someone with product sympathies who can act as a proxy for you?” This echoes an approach I’ve seen becoming more commonly cited–including last week’s Technology Association of Georgia presentation by Mike Cottmeyer–of having a Product Owner Team. The team consists of a handful of roles that must be addressed: Product Manager handling the outward market-facing strategic functions, product owner acting as the development liason and sitting with the development team and driving home the detail around the user stories, and potentially a user experience analyst and others. Thus as Roger Cauvin proposed, “one model is that product management is more market facing, while product owner is more inward facing.”
NOTE: Another great read about a similar topic was recently posted to On Product Mangement.
The Balancing Act: One major concern about this approach is “too many cooks in the kitchen,” or not having a single point of authority on the product. I think the split approach can work, if and only if the members are diligent about remaining aligned on a daily basis. Another alternative is a balancing act: The PM/PO must be accessible to the team at all times, yet must get in front of customers and the other teams within the company to ensure a successful rollout. This balancing act can work if the team is talented and can work (at times!) without direct input from the product owner. A few calls and meetings spread through the week is one thing, but if the product owner is rarely visible except for the daily scrum, even a seasoned development team may be hard pressed to succeed. Conversely, if the product manager never leaves the scrum room to speak with customers, the team is at serious risk of building the wrong product “successfully”!
Two Pounds In a One Pound Bag: Given more than a full-time job’s worth of responsibilities outside the scrum room, and nearly another within, it should be inherently obvious that a product manager should not be placed in the impossible scenario of performing product manager and product owner responsibilities on two products at once! I can also confirm this from personal experience.
Other Topics: Other topics were discussed, including
- how to gain the respect of the development team
- how to break up deliverables when more than one product manager is on a single product
- when are agile methods not suitable for product management
- How do product managers ensure the vision when agile delivery teams are focused on small pieces of work?
- If it all needs to be done why does it need to be prioritized?
- How do you roll up individual projects into an org-wide roadmap aligned with company strategy?
Plenty of great discussion on all points is archived and available in PDF (start at the bottom!). Enjoy your read!
Thoughts on Agile Product Management
4448 days
A couple of thoughts/lessons about Agile product management were brought to my attention this week.
First, a former coworker expressed that he spends time with his developers when possible to get their input when writing requirements. While technical team input is certainly warranted, some of the primary benefits of agile are harvested only when the product owner sits in the “war room” with the development team during construction of the product. My former coworker expressed that he travels, so this arrangement is followed when possible.
In an agile organization, it may be that to account for a traveling, semi-available product manager–one who may be doing exactly what his product needs, spending time in the market–the best solution is to appoint a full-time product owner to the product. The product owner can spend time with the development team to make product decisions on a story-by-story basis, while the product manager is in the market, attending trade shows and visiting customers. If the two are able to stay in concert, the additional investment can pay off with a product that meets two very important goals:
- Being attuned to market needs,
- Constructed to meet the vision of the product’s evangelist.
For additional reading on this topic, start with Rich Mironov’s insightful slide deck entitled “Agile Product Manager, Agile Product Owner.”
Changing gears a bit, Roger Cauvin this week retweeted a link to his classic post titled “Agile is Not Just a Development Methodology.” In it, Roger posits that the benefits a product manager can obtain by working in an iterative, inspect-and-adapt process are perhaps more significant than the benefits a team obtains when developers work in this fashion. A product manager can use the input from customers and the “business at large” when planning each sprint, rather than constructing a complete set of requirements up front and hoping they’re still correct by the time construction has completed.
This is certainly motivation to support an agile development team, and can apply to monthly releases or initial releases. The flip side is that there are (at least) three types of initial product releases:
- Initial releases where a minimum marketable feature set must be constructed before release can occur.
- Initial releases where the marketability is more nebulous, and where realtime input is necessary to identify the point at which the product can be released to market.
- Ongoing releases where customer input is consumed regularly.
When entering a market in which established players exist and where speedy release to market with at worst a comparable product is the order of the day, the product manager may already have identified a minimum feature set that–reminiscent of waterfall processes–must be constructed in order for an offering to be at all viable. Going forward from that initial release, additional features to be added to the product can be vetted against real initial-release customer feedback as well as market needs. During initial construction, the product manager validates the original assumptions and concentrates on the user experience, to ensure the best possible initial release.
When entering other markets, customers can be brought in to evaluate each iteration and can help to determine when the problem is solved “well enough” to bring it to market. This mindset may be hard to achieve in a SaaS environment, where a monthly release schedule dictates that a release will go to market on a schedule. Teams may address this challenge in a couple of ways:
- Conducting work on solving the problem in each iteration and release, but not surfacing the functionality until the team decides it’s ready.
- Skipping a monthly release but still iterating, and releasing only when the feature is “ready for prime time.”
The third category, where a regular release schedule is maintained and customers are regularly consulted, is the most closely aligned with Roger’s position and is where agile product management can truly deliver the highest ROI.
Book Review: Agile Excellence for Product Managers
0483 days
Agile Excellence for Product Managers by Greg Cohen is, in my view, the best introductory “how to and why” guide to Agile and Scrum for product managers available. There are other great resources touching on specific elements of methodology–such as Mike Cohn’s User Stories Applied–but Agile Excellence puts those techniques into context and explains the benefits of iterative development, the impact of iterative development on how the product manager conducts his activities and why it helps the product manager conduct those activities better than under a traditional development methodology.
Agile Excellence introduces the product manager to agile in a deliberate sequence. Starting with the benefits of iterative development, Cohen covers the specifics of Scrum and then gets into the details of release planning. In my experience, some teams try to “sprint through the backlog” without considering the contents of a specific release — the release planning chapter illustrates a technique for thinking this through to provide marketable value to customers over a series of iterations. To bring the product manager up to speed on writing requirements in the form of stories, Cohen goes into detail about user story management including the types of stories that exist and techniques for splitting the large ones. Examples are provided to illustrate when a story is too big to estimate granularly. This section is not nearly as comprehensive as Mike Cohn’s book, but it’s good enough to get started without lacking the basics.
Cohen shows how to move from ideation to a prioritized backlog, and how the team is able to deliver value to the business early and often by doing so. Agile Excellence walks through creation of a product strategy, followed by a release plan, creation of the product backlog, and finally estimation of the stories using the Planning Poker technique. With a team working on an estimated product backlog, Cohen considers how a product manager interacts with the team and with the business at large (including customers), and discusses signs of trouble and how to react. Finally, for context, Cohen spends a bit of time on XP and Lean development including Kanban.
One of the important points Cohen makes is that Agile and Scrum are essentially a project management approach rather than a development methodology. Development teams need to adopt new techniques to meet the tight deadlines agile demands, but these techniques are not elements of agile. Agile simply assumes the team is “self-organizing” and will make the changes necessary to succeed. The fact that those changes often include pair programming and test-driven-development is left to the development team to discover, however it is useful for a product manager to be aware of them in the event they are evangelizing agile to an organization.
I highly recommend this title for product managers new to agile, and to those needing a refresher. This book puts agile techniques in context, gives enough “in the weeds” level detail, and explains why these techniques are useful and why they make a difference. It’s the book I wish I’d read before beginning to work with a scrum team.
So many products, so few gems
1488 days
The pace of technology innovation is unabated, even growing, and yet it’s commonplace to see new products released that don’t resonate. Either the products are good but are poorly marketed to their target buyers, or they are not solving a real market problem. I believe this signifies a need for better product management in technology companies.
Jim Holland speaks to this in his recent On Product Management post, A Product Leader’s Perspective of CES [the Consumer Electronics Show]. In it, Jim summarizes the situation:
It’s a shame really. You know the products. Ones that were designed and developed because they COULD, not because they SHOULD.
Jim cites a previous post I’d written in which I proposed four artifacts that a product manager can use to define a proposed product:
- The problem being solved
- Buyer and User Personas
- Value Proposition
- Solution Workflows
In an agile or scrum environment, it may only be the core workflows – much of the finer detail and other workflows may be emergent. But the basic workflows must be in mind, or there isn’t enough definition around what is to be constructed.
I propose that if the product manager or product owner can confidently communicate these four items, he is on the way to delivering something of value to the market. The challenge is to clearly identify these items before building the product — and if they can’t be identified, this is a golden opportunity to avoid investment in a product that will become one of the many developed just because someone could.
Recent Comments