Economics are a big deal when deciding whether to go with a NoSQL, NewSQL, MPP DBMS, or traditional RDBMS.
Many of the products (in all four of these categories) claim that economics are on their side, because either…
- Their products are ultimately cheaper than the alternatives, or
- Their products produce greater benefits, that dramatically overshadow their cost.
The first is basically a Total Cost of Ownership (“TCO”) argument. The second is about higher ROI (return on investment) or shorter payback periods, versus the alternatives.
The TCO, ROI, and payback period for any particular data store (be it of the NoSQL, NewSQL, MPP, or RDBMS variety) will vary greatly according to the application. It is important not to take vendor claims of ”X% improvement” for granted.
Instead, create your own economic model for quantifying expected costs and benefits. Here are some factors to consider:
1.Upfront Hardware costs – Many vendors claim their products require cheaper hardware, either by using fewer machines or by using cheaper machines. Hardware costs affects both up-front project costs (CapEx) as well as yearly maintenance fees (operational costs) paid to the hardware vendors. Hardware costs can usually be further subdivided into processors, memory, storage, network interfaces, and “other” (racks, load balancers), dedicated storage appliances, etc. The cost of memory can be a significant driver of costs, as well as the type of storage used (SSDs, SANs, RAID arrays of regular old hard disks, ….)
2. Software license costs & maintenance – The cost here can vary wildly, from $0 for one of the many open source NoSQL solutions, to millions of dollars. This item includes up-front CapEx costs – as well as the annual maintenance bill, typically about 20% of the purchase price.
3. On-going Software support costs – If you buy a commercial data store, customer support is probably included in your annual software maintenance bill (see the previous bullet). But if you are looking at open source, you will want to find a vendor that can provide ongoing software support. And that costs, even if the software itself is free. This is an ongoing operational expense.
4. On-going Hardware support costs – This is a support & maintenance contract on the hardware your purchased in #1. The cost varies per vendor, but is usually calculated as a percentage of the hardware purchase price – usually somewhere between 8% and 20%. For commodity servers (generic Intel- or AMD-based Linux boxes), many organizations forego official support contracts and have their own IT staff support the machines.
5. Power costs – If you use fewer boxes, or use more energy efficient hardware, then your power bill will be lower — sometimes significantly so. If you want to get fancy and impress others with your “green-ness”, consider calculating your carbon footprint, and take into account any Carbon Offsets you’d purchase to reduce the system’s environmental impact.
6. Administrative costs – This bucket includes the cost of the staff needed to keep your system running and healthy — usually the full-loaded salaries of the DBAs and other administrators. In general, the more hardware you are running, and the more instances of software you are running, the more administrative staff you need.
However, different products have different demands of administrators. For example, “sharding” (sensibly dividing up data across multiple nodes) can consume a lot of administrator time if done manually, but many NoSQL and NewSQL systems do this automatically. Recovering from downtime – both planned and unplanned – can consume large amounts of administrative time, so the availability of the system impacts these costs. Other tasks that can take up a lot of time, but vary considerably from system to system, include: time spent on upgrades (especially if updates to the software come out very frequently), time spent on performance tuning, and time spent on monitoring, backups, etc. Different products, and different rules governing data and IT, require varying levels of attention from human administrators.
7. Developer productivity - If the structure and type of data in the datastore changes, often the applications that use the data store need to be changed as well. So, you should account for the fully loaded salaries (or consulting fees) for the programmer time needed to make these changes.
8. “Hard” revenue impact - Different configurations of products will achieve different levels of availability. This ultimately translates into some amount of system downtime or time when system is overloaded. If your system is essential to your company actually making money (for example, it is an e-commerce store), than every minute of downtime results in lost revenue. If the system is still “up” but is overloaded, then you lose the ability to serve some customers who would have bought. Again, the result is lost revenue.
9. “Soft” revenue impact – This includes things like “greater customer satisfaction”, “higher accuracy”, “better response times” – things your choice of system might affect that will impact customers, and will thereby affect the amount of revenue they give your company. ”Soft” costs are very real, but are often difficult to quantify.
Note that the above factors assume that you will own your infrastructure – the hardware, software, etc. ’The model needs tweaking / revamping if you are “renting” infrastructure in the cloud, by using something like Amazon Web Services, for example. (In the future, perhaps I’ll post about the economics of cloud deployments).
At most companies, everyone agrees that Win-Loss Analysis is very important. After all, without understanding why you are winning deals and why you are losing, how are you to know what you’re doing right and what you need to change? For example:
- Are your sales people blowing it by not properly qualifying the deal or understanding the prospect’s problems?
- Is your product a true winner or is it deficient in critical ways?
- Are your products priced competitively?
- Are you lacking in other components of the big picture, such as professional services or customer support?
However, despite the benefits, Win-Loss Analysis rarely gets done. The product managers and product marketing managers, who are traditionally responsible for Win-Loss, are usually too busy and overloaded.
But there is hope. Win-Loss Analysis is a perfect job for an outside consultant or contractor, and can often be done extremely cost effectively while freeing product management and product marketing staff to focus on strategic tasks that can’t be outsourced.
In fact, a consultant might get better and more accurate results that an employee because lost prospects are more likely to be honest with an outsider.
- They don’t have to worry about offending the sales person, the product, or the vendor as a whole.
- They don’t have to worry about the consultant using the Win-Loss conversation to try re-opening the sales process – a decision prospects are often loathe to revisit after a protracted selection process. This fear is a major reason lost prospects turn down requests for Win-Loss interviews.
A Win-Loss consulting engagement usually involves interviewing a majority of the customers and lost prospects from the last quarter or half. The consultant has a short conversation with the internal account team for each customer or prospect to learn their take on why the customer was won or the prospect was lost.
Then, the consultant interviews each customer and prospect, delving into the areas most likely to provide actionable feedback. Depending on the account, topics might include the business problem driving the product purchase, product fit (or lack of) with the problem, competition, account team dynamics, and the customer’s internal decision-making process.
If done right, these conversations — without fail — uncover distinct patterns across several customers. Follow-on conversations — both internally and externally — dive into the causes and effects of these patterns. Finally, the consultant works with internal employees to identify specific initiatives and actions to improve the situation.
Now, of course, the mandatory plug. At Sure Product Consulting, we do lots of win/loss analysis projects. In fact, some clients have a perpetual subscription with us, where we attempt to interview every single win and loss, and report out the results to the client every quarter.
Please contact us to discuss how we can help you get started with win/loss analysis.
Content Management is huge in enterprise software, and thus the Content Manager Pattern is one of the most important high-level Product Patterns. Content management is the primary function of most software described as a platform, server, or online service. It’s not just limited to the realm of official “Content Management Systems (CMS),” and what I mean by “content” is much broader
To “manage content”, software platforms/servers/services usually offer some subset of the functionality described below.
The Content Manager product pattern
What is it?
- Stores, secures, shares, organizes, and searches content.
- The content might be user-generated or from an external system.
- Example: Gmail’s content is both user-generated (messages created by Gmail users) and from external systems (messages sent to Gmail users from outside Gmail)
Where to find it?
- 99% of products described as “servers” or “online services” have the Content Manager pattern at their core.
- Most multi-user software products have the Content Manager pattern at their core, even if they are desktop clients or mobile apps.
- Users need to share content with other users (example: Salesforce.com Sales Cloud users share data about prospects and opportunities, Craigslist displays user-created advertisements to other users)
- Users want to store their content online so that they can access it from anywhere or use it with other online tools. (example: Dropbox, Shutterfly, Facebook, Gmail)
- An “engine” (see the upcoming Content Generator pattern) needs a place to find source content and to store result content (example: for a business intelligence (BI) system, a report design is source content and the result content might be a report with the data for the day 4/30/2012).
There is obviously a slew of user stories underneath each of the following functionality buckets, but in this post I’m only going to cover typical functionality at a very high level:
1. Storing content
This lets users put content into the system, and provides the baseline functionality everyone typically expects.
- Basic “CRUD” (create, read, update, delete) functionality, plus copy
- Ways for users to publish/deploy/import content into the system. This might include the concept of content statuses like “drafts”, “pending review” and “published”
- Ways to move content to a different location within the system
- Way to unpublish (but not delete) content
- Export content to an external system or file
- Ways for users to “link” to or refer to the content from elsewhere
2. Finding content
Once you have more than a few pieces of content stored in a system, you need to provide ways for users to find both specific pieces of content as well as discover relevant content they might not have been explicitly searching for. Typical functionality includes:
- Content properties (such as date modified, author)
- Quick search, advanced (property-based, wildcard-enabled) search
- Content listings - filterable and sortable
3. Organizing content
Users like to organize their content in ways that make personal sense to them, mainly so they can quickly find their content again. However, the desire to organize is still there even if you provide a top-notch, all powerful search. To this point, when Gmail was first introduced, it did not support folders nor a way to quickly keep messages but move them out of the inbox. Google quickly introduced those features based on user feedback. Typical organizing functionality includes:
- “Home location” for each user – where s/he can quickly find his/her own content immediately after logging in.
- Ways for users to provide and change user-friendly names and descriptions to content, author-provided and user-provided tagging, categorization/folders
- Favorites & bookmarks
4. Securing content and providing access
These Content Management features ensure users can only access the content to which they are authorized. It assumes a user management system (a different Product Pattern that I will hopefully cover in the future).
- Administrators can decide what users are allowed to access what content, including which users are allowed to share with others.
- Users can choose to share content with specified other users, and specify the “proper level” of sharing for that user
- Privileges / permissions on content
- Content Ownership, and differences in ownership versus authorship
5. Sharing / Social
These features primarily let users provide some information to others about WHY they are sharing content and how to use it. Also, single users may use these to remind just his/her “future self”, and no other users, of important things about the content.
- Discussion: comments / threaded discussions
- Popularity measures: followers/friends/fans on the content, likes on the content, most read, etc
- Quality measures: ratings, reviews, vote ups / vote downs
- Suggest related content: similar content, recommended based on your ratings of this piece
- Share with others: Email, Facebook / LinkedIn / Twitter / Google+, other
6. Advanced Content Management
- Editor-designated “Featured” content
- Versioning of multiple revisions
- Managing dependencies between content
- Content expiration (useful for job posts, ads, etc)
- Archive & purge of content in system
- Backups of all content in system
In my posts about Product Patterns, I’ve mentioned the word “content” a lot. I’ve even mentioned a few high-level product patterns called the “Content Manager” and “Content Authoring Tool.”
This is an important product pattern because basically every piece of software that touts itself as a “platform” or “server” or “service” uses the Content Manager pattern. The Content Manager pattern underlies just about any software or service where people share or collaborate.
But first, before I get into the details of the Content Manager product pattern, I need to first define what i mean by “content” because I am using a much broader definition of “content” than many people.
But what do I mean by “content”?
Good question! I tend to use a broader definition than you might think. My definition is not limited to what’s managed by an official “Content Management System” (aka “CMS”), like Microsoft Exchange, Drupal, or WordPress.
By “content” I mean any type of “object” that either a user creates, that the platform/server itself creates, or that a third-party system created.
This “content” is managed by a server to allow users to use it, share it, secure it and control access to it, etc. (This definition needs improvement, so please comment below if you have suggestions on how to improve it).
Some examples of “content” from the enterprise software world:
- In VMware vSphere, a virtualization platform, the “content” are virtual machines.
- In Jira, the content are issues/bugs that need tracking.
- In Salesforce.com, the principal content are leads, opportunities, and profiles of prospects and customers
- In Eclipse, the content are user-created code files, libraries, and executables.
- In the Oracle Database, the content consists the “user data to be stored in the database and metadata that describes that data.
- In Microstrategy, a business intelligence platform, the content includes OLAP cubes, reports, and dashboards.
- In Microsoft Exchange Server, email messages are the content.
- In WebEx, the content is presentations and meetings.
- In DemandTec, a promotion and price optimization SaaS platform for retailers, the content are prices for individual retail items and promotion plans.
And here are some content examples from the consumer side
- In WordPress, a blogging platform that has evolved into the leading CMS (Content Management System), the “content” consists of blog posts, articles, and snippets of web pages.
- In Google Docs, the content consists ofdocuments, spreadsheets, presentations, forms, and drawings.
- In Shutterfly, the content are photos and albums.
- In MediaWiki, the software that powers Wikipedia, the content are wiki pages.
- In craiglist.com, the content are the user-created advertisements.
- In YouTube, the content are user-created videos.
- In Gmail, the content consists of email messages.
- First, “Content” is not limited to just the “Content Management System” (CMS) category of products.
- Second, “Content” has a broad meaning, ranging from spreadsheets to virtual machine images to sales opportunities. Content management is THE MAIN activity performed by most software described as a platform, server, or online service.
Since I’ve become attuned to Product Patterns (buckets of software functionality that appear in product after product ) I’ve noticed dozens of them. Maybe more. Some are big, top-level patterns. And some are really sub-patterns, that exist in the context of a larger pattern.
I’m going to start with a few of the high-level Product Patterns that I see again and again in enterprise software.
- The Content Manager – manages some kind of content: secures it, organizes it, makes the content searchable, lets users share it
- The Content Viewer – renders content for viewing by humans. It lets users view and navigate through the content, not edit it. For the ability to both view and edit content, see the Content Authoring Tool Pattern. (Many software platforms don’t have a Viewer because they simply use the web browser to view content, or because they use a Content Authoring Tool to both view and edit.)
- The Content Generator – takes one type of content and generates a new kind of content from it. (like generating a populated dashboard from a chart design).
- User Manager – manages logins, user accounts & profiles, etc.
- The Workflow Manager – automates a business process by routing content,approvals, tasks, and the like to users.
- E-Commerce Manager – self-evident, but when built into a software product it’s often to let the user buy more or renew more licenses to run itself.
- The Content Authoring Tool – lets users create content. Often this content is then deployed to a server with Content Manager capabilities, and then managed by it.
Each of these high-level Product Patterns breaks down into several sub-patterns that I’ll cover in more detail some other time.
Most software “platforms” or “server” products — whether they are installed servers or software-as-a-service offerings — are implementations of at least one or two of these patterns, and sometimes all seven. Some examples:
Product Pattern Examples
Microsoft Office tools (Word, Excel, Powerpoint) – These are “Content Authoring Tools.” The content: documents, spreadsheets, and presentations.
Wikipedia / MediaWiki & other wiki platforms - Most Wikis are a combination of a Content Viewer, Content Manager, Content Authoring Tool, and User Manager. Most users just view pages (via the Content Viewer). Other users (authors and editors) log in using the User Manager and create and edit Wiki pages. And the Content Manager gives all users the ability to search content, to categorize content, and track revisions to the content.
Craigslist is a Content Manager, User Manager, and a Content Authoring Tool. The content is primarily user-written advertisements. Viewing
Kickstarter is a Content Manager, User Manager, Content Authoring Tool, plus E-Commerce. The content is mainly user-written project descriptions/advertisements.
A Business Intelligence platform like Microstrategy is a Content Manager of report and dashboard designs, plus a Content Generator that runs the designs and populates them with current data, a Content Viewer to render the reports, and a User Manager. The content is reports, analytic data cubes, and visualizations.
Salesforce.com’s Sales Cloud is a combination of six Macro Product Patterns:
- A Content Authoring Tool to let users create content like new leads, opportunities. customer profiles, and other related info,
- A Content Manager to secure and manage access to , Content Generator, Workflow Manager (to move
- A Workflow Manager to route leads from one stage to the next and collect approvals
- An E-Commerce Manager to let Sales Cloud customers convert from a trial license to a paid-for license, and to purchase extra seats.
- A Content Generator that generate sales forecasts, reports, and dashboards from user-entered data.
- A User Manager to manage user logins and accounts.
Facebook is primarily a User Manager plus a subset of the Content Manager (search, routing of status updates to other users).
Over the past 10 years, I’ve probably analyzed the functionality and usability of close to 800 (yes, I’ve counted them!) software products and online services.
Why so many? Because playing with software is not just my job, but also my weird hobby. I’m always on the hunt for a new application to solve whatever problems I encounter in my life and business.
I’ve done this analysis through the lens of someone who is a product manager by training and experience, as someone who does a lot of competitive analysis work for software industry clients, and as someone who has deep familiarity with the way users interact with software products (especially business applications) and their expectations of them.
After working with the first hundred or so products, I realized that about 80% of the functionality in each of these software products was essentially the same. For example:
- Most B2B servers let you integrate with your business’s existing security systems and user directory.
- Most content designers provide (or should provide) a way for users to preview the content as it would be displayed to other users.
- Most installed software provide (or should provide!) a way to let users easily upgrade to the latest version of the software, without the user losing work.
- Most platforms that generate new content, or receive new content from users or outside sources, needed a way to notify users of what’s new.
- Much software that manages content provides a way for users to give reviews and feedback about the quality that content.
And so on. Deja vu. Over and over. No matter what the domain, the business problem, or the type of user, the same types of functionality and use cases come up again and again. For my product management clients, I find myself working on requirements for the same buckets of functionality as I had for many other clients in the past. Even for clients that are in very different problem spaces.
Because product managers love to name things, I decided to refer to these recurring bits of functionality as “Product Patterns.”
I tried researching what others had discovered about “Product Patterns”, and I didn’t turn up much. Perhaps I have been looking the wrong places or with the wrong Google keywords. (If you know of other people talking about these, please share the sources with me in the comments).
In contrast, I did find a lot of information about software design patterns, but these were at a lower level—deep in the code – than what I was looking for. And I found some information about patterns for user interaction design in an excellent book by Jennifer Tidwell. But again, it was not quiet what i was looking for. Software Design Patterns were great tools for software engineers. User Interaction Patterns were great tools for user experience designers. But what about some pattern tools for product managers?
What I was looking for were descriptions of common Product Patterns, the common functionality building blocks that are used to develop software product. I wanted something that would describe the patterns, what they were used for, how to determine which were applicable to market problems my product was attempting to solve, what questions to ask customers and prospect, tips for using them, what traps to avoid, sample user stories, etc. I didn’t find this, so, I started to create descriptions of Product Patterns on my own. I then started using them and refining them with my product management consulting clients.
Over time, I hope to share some of these patterns in blog posts here.
My goal for posting here is twofold: 1) to motivate myself to better structure my thinking on product patterns, 2) demonstrate expertise to potential clients that need someone to assist with requirements or user stories.
Below is an online Q&A from a presentation I gave on Agile Product Management. Just wanted to share….
Q: How do you deal with a management team that is entrenched in the Waterfall method and a development team that is Agile from a roadmap and planning perspective?
Sue Raisty-Egami: Management teams usually respond to results. If you have a successful Agile release that comes out faster with higher quality and more predictability, you’ll often see management teams change their ways.
That said, as a PM you still have to communicate a long-term product vision and roadmap to an executive team. You just have to get more skilled at not saying exactly WHEN each feature will come out plus make sure that Management view the roadmap as something flexible and subject to change as you learn more about the market. Hopefully, they will recognize that you are already basically changing your roadmap all the time – but usually it’s after a release came out and the results were not what you expected. Agile just gives you the construct to make these changes BEFORE the bad results roll in.
Q: How does User Interface Design work best within Agile … like other longer-term consideration like architecture? How do you police design decisions to ensure consistency across stories, iterations, releases, and multiple product lines?
Sue Raisty-Egami: This is another one of those challenge areas. Like PM, user interaction design was not explicitly addressed in Agile methodologies. What I’ve seen work with some limited success (no home runs here) was having a UI designer on each team that sits in the room, attends Scrums, etc… But these designers also have a weekly pow-wow with the other UI designers on other products. They show off their work to each other and review it (much like a code review), and they spot a lot of areas to more holistically improve usability.
Architecture is another thorny one. Some companies have an architecture team that lives together and is exempt from the entire Agile process and does the traditional design docs. On the other end of the spectrum, some companies assign an architect per team, and during the weekly “Scrum of Scrums” the architects are among the attendees and seek areas of synergy, consistency in stories, etc…
Q: Many companies claim to have Agile. In your opinion, where does the waterfall end and agile begins?
Sue Raisty-Egami: Yes, everyone claims they are doing Agile even if most Agilistas would disagree. I believe the most common methodology in use now is what the practitioners often call “modified agile,” where the process itself is very waterfall-ish but the releases are pushed out more frequently, an interval between 6 weeks and 3 months. I would actually call these “tiny waterfalls” instead of “agile” because they neglect in-flight customer feedback.
I personally think the nomenclature and exact definitions are not important as long as you are doing better with your new “agile” process than you did before with waterfall and you are making further attempts to continually improve.
That said, in my mind the “bare minimum” Agile has 2-6 week iterations where a semi-usable product comes out, documentation and needless process are kept to a minimum (not eliminated, just kept to a minimum) in favor of building, and there is a way to get customer/stakeholder feedback into the release at several points prior to release.
Q: As we are moving to Agile, Development has identified the Product Managers as the Product Owners AND Proxy Customers. In my case, for 12 dev teams. Any suggestions?
Sue Raisty-Egami: 12 dev teams! One PM, playing both the role of PO and Proxy Customer! That is ludicrous and highly unrealistic. How can you possibly intelligently understand the problems each of these 12 products address, develop an appropriate backlog, spend time interviewing with customers, write user stories, and attend 12 meetings a day (even if they are only 15 min a piece – that’s 3 hours!).
You need more help. I can’t say whether it’s a real PM or a business analyst or whatever, but there is no way you could do these 12 products justice and still do your main PM responsibility – being the voice of the customer and learning about their problems. You need to have a good conversation with your management.
And if that doesn’t work, I recommend you start drinking mojitos. Often.
Q: Thoughts on managing a product backlog that has 200+ items?
Sue Raisty-Egami: Sure – I’ve done that. Basically, I kept this spreadsheet that listed each feature in the backlog, with a 1-2 line description of each (otherwise, with 200 items you forget what each item means), the “category” (example: “disaster recovery”, “user interface), and a priority measure (I used 1-10). I could then sort the thing relatively quickly in different ways to come up with features for the next iteration based on priority, grouping similar items together, etc.
Note that I am not really operating at the user story level. My “features” break into several user stories a piece. Some of the features I track are perhaps at the “Epic” User Story though.
Best thing about the spreadsheet is it is really just for YOUR use – not the entire team’s. You can thus adapt it to whatever you need to do your job. If you can avoid it, try to resist the temptation to over-engineer this and use a full-blown requirements tracking system to manage your backlog. I find these systems are too much for prioritizing a backlog and add the very overhead to the process that you are trying to avoid with Agile.
Q: What if the team members leave the company while project still going on and how do we manage this situation in Agile environment?
Sue Raisty-Egami: I assume you are talking about a developer leaving?
First, cry and mourn the loss, for at few minutes anyway.
Second, look on the positive side – in an Agile environment you have more flexibility to deal with this loss. Because your team was meeting daily (or close to it) and the iterations were much shorter than waterfall release cycles, it is unlikely that your team member retreated into his cave for months and created a morass of spaghetti code that no one can figure out – s/he wouldn’t have had the chance. With Agile, it’s more likely that someone else can pick up his/her critical projects.
Third, accept that you’re going to have to either extend the release schedule or reduce the functionality in each iteration and, ultimately, in the release – even if there was a replacement team member tomorrow.
Q: What is the typical timeframe to go through the stages in an individuals companies “hype cycle?” Does Gartner give any guidance on this?
Sue Raisty-Egami: Virtually every technology or new approach worthy of notice goes through a hype cycle, but the time spent in each phase really depends on the technology and the overall cultural environment. For example, the phases lasted a lot longer a few decades ago – witness the invention of the Internet as an example. It took decades to reach the “height of inflated expectations” and then we hung out in the “trough of disillusionment” for a year or two post-bubble collapse. For newer technologies and newer approaches, we now move through the phases more quickly. But for most it will still take years to make it through the hype cycle.
Q: When should release content and date be defined? Beginning of release or end?
Sue Raisty-Egami: Most commercial software vendors seem to use a time-boxed approach with Agile, meaning they specify a target release date up front. The PM should have light-weight “release plan” at the beginning of the release, meaning a list of user stories/features from the backlog that he/she wants to ultimately address in that release. This would be a flexible list and subject to change as iterations proceed and more is learned, but it should provide an overall goal for the release and idea what it is about ahead of time. As iterations proceed, you usually see the release plan / user story list scale back and evolve to address mid-release feedback and the realities of the release date.
So, that’s a long-winded way of saying you do define both the release date and release content up front. The date is usually the firmer of the too. As the iterations tick away, the release content always changes.
That said, I really try very hard not to make any public declarations of release date or features until we’re at least half way through. I’ve pushed out dozens of product releases (all of which required at least 3 months of coding effort), and all kinds of wild stuff can happen — things like acquisitions/mergers, major changes in corporate strategy, massive layoffs and restructuring, etc. In software, these things happen ALL the time and are hardly unusual, but they throw a huge wrench into the release schedules and features delivered by even the most Agile team.
I love it when a gnarly technical concept can be elegantly explained via a good analogy. In fact, I have found myself searching for these perfect analogies throughout my career.
I’ve been working on NoSQL projects of late, and found the following two articles – both with brilliant analogies — to be very helpful:
- “Starbucks Does Not Use Two-Phase Commit” – This article is not about NoSQL databases per se, but it does illustrate the point that sometimes you can afford to lose a transaction or have your database in an inconsistent state temporarily.
- “A Plain English Introduction to the CAP Theorem” – this is a brilliant explanation of the trade-offs you need to make when scaling a database: consistency, availability, and partition tolerance. If you’ve ever had a hard time wrapping your head around these concepts, this article will help.
- Crossing the Chasm, by Geoffrey Moore
- Inside the Tornado, by Geoffrey Moore
- Four Steps to the Epiphany, by Steven Blank
The following are not “absolute must-reads” but are very worthwhile:
- The Lean Startup, by Eric Ries
- Innovation Games, by Luke Hohmann
- Inspired: How To Create Products Customers Love by Marty Cagan
- Business Model Generation by Alexander Osterwalder & Yves Pigneur
- The Product Manager’s Desktop Reference, by Steven Haines
- The Art of Product Management, by Rich Mironov
- Dealing with Darwin, by Geoffrey Moore
I’ve read (or attempted to read) about every book on the market with the words “Product Management” or “Product Manager” in the title, and I would only recommend the ones listed above for high-tech product managers.
Many of the other books on Product Management are either 1) too broad, covering the gamut of banking products, consumer goods, automobiles, as well as high tech, 2) poorly written, or 3) perfectly fine and covering the same topics as the books I already listed, but not not as well.