The always incisive and effervescent April Dunford has a great post at her blog Rocket Watcher about the reasons why your start-up needs a website, before you have a product to talk about. I couldn't agree more, for the following reasons:
Customers are buying your business model, not just your product. Your product is one source of value to potential customers, but not the only one. A good case in point: the many SaaS start-ups that attracted a lot of initial attention, then quickly lost their users to competitive products. If there's more to keeping your customers than just the product, you'd better start communicating those other sources of value.
You need the opportunity to test your marketing. You won't get the communication right the first time, so market testing before the moment when you release the product is critical. Who wants to slave over a great new invention, only to discover that your marketing sucks?
You need early product feedback. All new products are based on a set of assumptions, some of which will be wrong. You can use your website to understand your potential customers better through the website. If there's something wrong with your personas, use cases, or any other guiding principles of prioritization and design, identify the problems now, unless you really enjoy re-engineering.
[More in a series of posts inspired by the "PM in an on-demand world" research that I've been doing. Here's the link to yesterday's thought du jour.]
During the research interviews about PM and SaaS, I was struck by how philosophical the conversations got. To the interviewees, SaaS was not merely a delivery vehicle, but a fundamental decision about their business. Bringing technology producers and consumers closer together forced many vendors to admit that they had a vague, incomplete idea of who adopts their products and services, why they do it, and how they do it. The subscription model led to many hard questions about how the company makes money. Marketers had to deal with a significantly modified value proposition, while simultaneously knocking down some new potential objections (most notably, security).
But those are just the most obvious consequences. The deeper we got into the research, the more I felt that we were talking about other ripple effects of SaaS, PaaS, and the other aaSes. At least a couple of Big Industry Trends – the kind that Very Serious People spend a great deal of time talking about – owe a great deal to SaaS. Without the success of SaaS, many organizations would not have been as open to embracing other changes. I'll mention just two of them, Agile and social media, among several that we'll discuss in the final report.
As promised, still more SaaS! Following an excellent day of discussion about PM in an on-demand world, I started over here at the fresh-out-of-the-shrinkwrap Forrester community site. Topic: On demand is a business model choice, not just a delivery mechanism. Discuss.
I'm working on a report about the role of PM in an on demand setting (SaaS, PaaS, and all the other aaSes). As often happens in discussions about PM, the role is a window into many bigger issues. Since their responsibilities span both business and technology, product managers and product marketers find themselves in the middle of many fundamental questions for technology vendors, such as, How often should we deliver something new to our customers?
That question has two sides: (1) how often do customers want to receive something new, and (2) how often can the vendor deliver it. Both questions can be difficult to answer. Customers often want tech vendors to deliver value faster, but they also complain if the changes happen too fast. Vendors know that they could deliver new technology every time they do a build, but they also know that the entire company (sales, marketing, support, etc.) won't be able to keep up at that pace. There must be some golden mean between the pace of technology production and consumption, but what is it?
By shortening the distance between producers and consumers, on demand, and SaaS in particular, has made it easier to reach a meaningful answer. The on-premise model creates a very long value stream between the development team at the beginning of the technology adoption process, and the users at the very end. In fact, adoption is, at best, a blurry image on the distant horizon of the development team's field of vision. Since the success of a development team's work products depend on its adoption, lack of information about adoption is not an information gap, but a yawning chasm.
I'm excited to introduce a new way for marketers and product managers to get answers to their most pressing issues and challenges. Forrester has launched an online community for technology marketers and product managers as the premier destination for leaders to exchange ideas, opinions, and real-world solutions with each other. Forrester analysts will also be part of the community, helping facilitate the discussions and sharing their views.
The community is open to all technology marketers and product managers.
Here’s what you’ll find:
A simple platform on which you can pose your questions and get advice from peers who face the same business or technology challenges.
Insight from our analysts, who weigh in frequently on the issues and point to relevant research.
Fresh perspective from peers, who share their real-world success stories, best practices, and templates.
Content on the latest technologies and trends affecting your business — from Forrester and other thought leaders.
I encourage you to become part of the community:
Ask a question about a business or technology problem.
Start a discussion on an emerging trend that’s having an impact on your work.
Contribute to an existing discussion thread from a community member.
Share templates with your peers for common artifacts like social media guidelines or campaign outlines.
Suggest topics for upcoming Forrester research reports.
This just in: a very interesting case study about Sterling Commerce. The company used portfolio management to align its product strategy, and gave a revamped PM organization greater authority over that portfolio. It's another good example of how technology companies are recognizing that product managers and product marketers are a strategic resource in their organizations, and a natural ally of executives who are trying to increase alignment.
A lot of my recent research – about SaaS/PaaS, Agile tools, requirements tools, and innovating with your channel – share a common conclusion: successful technology vendors see integration as more than just a necessary evil. Here's why.
Business problems drive technology adoption You can see this principle in action in the requirements tools market, which in the last decade has grown larger and more complex. Teams use these tools to address more than one type of requirements-related challenge, so it's easy to see why the tools themselves are now as diverse as as Micro Focus (née Borland) Calibre, Atlassian JIRA, Ravenflow RAVEN, and VersionOne's Ideas Management module. If your problem is, "People don't like using our product," you might look at a visualization tool like iRise to shorten the feedback loop, leading to better design decisions. If, instead, your problem is, "We don't have a good business justification for what we build," you might look at IBM Rational DOORS to evaluate the pros and cons of alternative scenarios for what goes into the next release.
Tomorrow, May 6, I'll be talking about the way in which product managers and product marketers in the tech industry are helping executives fix misalignments in their company. The technology goes here, the business goes there, and PM is in the thick of it.
This alliance between PM and executive management pushes PM into an increasingly strategic role. As a result, PM teams are changing their job descriptions, departmental structures, to-do lists, and objectives. Some investment is required, but the payoff is big.
Ryma Technologies is the organizer and sponsor of this webinar as part of their CxO series, scheduled from 12 to 1 EDT / 9 to 10 PDT. You'll find more information at this link. See you there.
In the tech industry, the "tell me a story" approach to product requirements – personas, user stories, use cases, visualizations, etc. – has made a bigger impact than many people may realize. Not only has this new type of content resolved many problems that existed with requirements, but it has led to a brand new way of looking at requirements. By thinking of requirements as stories, it's easier to figure out what kinds of requirements we need, and why we need them.
A tale of two mini-series
The fundamental question when writing any kind of story is, "What are you trying to convey?" I was thinking of exactly that question while I was watching the HBO mini-series The Pacific. I probably wasn't the only person to expect The Pacific to be the same kind of story as Band Of Brothers, just transplanted from the European to the Pacific theater of operations. I was wrong.
As it turns out, the new series has a very different kind of story to tell. Band Of Brothers depicted the experience of combat, in (literally) gory detail. While The Pacific does have more than enough battle scenes, it also tries to show military life beyond the battlefield. For example, one episode focused on the painful romantic choices that young people stationed in faraway lands have to make. Another episode depicted something rarely seen in war movies, the psychiatric casualties of war. Far more than Band Of Brothers, The Pacific shows more of the atrocious things that young men under brutal, terrifying conditions are capable of doing.