Inbound marketing and product positioning

According to Wikipedia, inbound marketing is, “A marketing strategy that focuses on getting found by customers.”  (http://en.wikipedia.org/wiki/Inbound_marketing)  One way that this can be done is by producing relevant content via a variety of social media channels, which gets indexed by the search engines.  If your content is easily found by the search engines, customers will find you when searching for keywords related to your product or service.

Product managers can use inbound marketing as a valuable tool for ensuring that their products succeed in the market.  As an example, one important job of a product manager is to actively manage a product’s positioning.  Here are some ideas for how to use inbound marketing to strengthen a product’s positioning:

1. Have a Twitter account dedicated to your product.  The key is to consistently tweet about topics that are germane to your product space.  Ensure that tweets incorporate information that communicates the product positioning.
2. Have a blog where content related to your product space is posted.  As with tweets, it is important that the blog posts remain focused on your space.  Then, ensure that the blog posts present a consistent positioning message for the product.
3. Create user forums and online communities where your product can be discussed.  If any of the threads discuss your product’s value proposition in a way that is not consistent with the positioning, this can be a clue that the positioning needs to be better communicated by the product team.
4. Make sure that search terms that are used to find your product produce search results that are consistent with the product’s positioning.
5. Get thought leaders in your product space to talk about the key market problems that your product solves.  If possible, help the thought leaders to comment on your product in a way that is consistent with the positioning.

Which of the above strategies have helped you to strengthen your product’s positioning?

BPMA Meeting: Product Launches

At a recent Boston Product Management Association (BPMA) meeting, the panel discussed product launches from two different viewpoints.  One panelist presented the B2B viewpoint, and the other the B2C viewpoint.  A major theme for the night was that, although B2B and B2C product launch strategies are often very different, they also share a few things in common.   Furthermore, it was noted that B2B and B2C product launch strategies might be starting to share more in common due to the use of social media.

Below I noted a few highlights of the discussion.   Some of the similarities between effective B2B and B2C launches that were mentioned include:

• Customer-facing presentations and collateral should not be overly technical and saturated with feature descriptions.  Instead, they should offer simple messages that describe real-world problems that the product solves.
• It can be beneficial to take more risks in the tactics used for the launch strategy, rather than rely only on traditional techniques.
• It is useful to boil down the marketing message to one key problem that a product solves.  This can pique a customer’s interest to learn more about a product’s other benefits.
• Product development prior to the product launch should be consistently driven by customer and market input.
• The beta program should be core to the launch strategy.  Furthermore, the beta program should involve customers with the product early enough so that there is time to make customer-driven changes prior to the launch.
• Social media tools such as Twitter and LinkedIn can be used to identify product experts and constituents in a particular market.  For example, a search could be done to locate everyone with “open-source middleware” in their bios, and get this targeted audience involved in the launch.  This audience could promote the launch by mentioning it in articles, conferences, etc.
• YouTube and other online video hubs can be used to widely distribute product messages that are compelling to customers.
• Product Marketing should not wait until the launch to begin creating product messages and content.  Instead, development of the messaging should be incorporated into the product development process as early as possible.
• It can be effective to distribute product messages from multiple channels.  Examples are paid advertisements, webinars, Twitter, YouTube, and press releases.

Core team review

Let’s say that you are tasked with writing a product requirements document (PRD).  Actually, it could be any type of written proposal, slides, etc. in various professions, but let’s use a PRD for the sake of example.  I like to start by brainstorming with others, outlining ideas, analyzing the market, talking to customers and internal experts, and then starting to write.  This is a great start, and at some point a cohesive document starts to come together.

Sooner rather than later, it is critical to start the review cycle.  The idea is that timely review and collaboration with the “core team” trumps trying to get it right on one’s own.  More specifically, reviews that are “early and often” seem to produce the best results.  The core team that I refer to typically consists of one document owner, plus two others who are close to the product in question.  Often the document owner is the person who actually writes the document, and the other two members actively participate in the whiteboard discussions.

Throughout the creation of the PRD, I like to schedule document review meetings with the core team 3-7 days before the document is due to be distributed to a larger audience.  This benefits everyone in several ways:

1. The review gets the team in the same room to focus its attention on the changes to the document.
2. The review ensures that the core team is aligned on the changes before distributing to the larger audience.  Then, when a review meeting with the larger audience happens, the core team is on the same page and the meeting goes a lot smoother.
3. Because the core team review is done 3-7 days before the larger distribution, the document owner has time to incorporate any revisions from the core team.  This is important for keeping the project schedule on track.  I have found that regardless of what the document changes look like since the previous revision, there are always significant revisions that come out of the core team review.
4. Ideas are solidified within the core team.  Even though the core team likely developed some new ideas at the previous review, the new ideas are often not crystal clear until they are documented.  There is nothing quite like seeing the ideas written in black and white to add clarity.

In summary, timely document reviews with the core team are a simple thing to do, but they make the PRD creation process go much smoother.

Agile Bazaar September 2010

At the September Agile Bazaar, the panel discussed some challenges and best practices for off shoring software development projects.  This was a topic that I related well to due to what I have seen in my own career.

First let’s summarize what the panel discussed that does not work well.  For one, it can be very difficult to take code that has been developed over time and is core to a product, and send it to an offshore team to work on.  This is because there are many intricate details to learn about the code base and it is very difficult to transfer this knowledge to a remote team.  This assumes that spending the time to do this knowledge transfer is even an option.   If the knowledge transfer is not done, the problem is compounded further.  Similarly, it can be difficult to have the local team work on one part of a project, and have the offshore team work on another part if there are a lot of dependencies between the two sets of code.

A project becomes particularly difficult when there are not at least a few hours of workday overlap between the two development offices.  In this case, the only way to communicate via phone is during the very early morning or night.  If the workday time overlap does not exist, it is important for both the local team and the offshore team to share in working off-hours.  Another challenge that was discussed is planning meetings.  These meetings can be difficult with offshore teams because phone calls lack the dynamic interaction that is possible in-person.  As a result, it is often the case that some team members on the phone call do not speak up or participate in decision-making the same way that they might participate in person.

Now let’s look at some best practices.  First, consider the goals of the project carefully to determine whether off shoring makes sense for a particular project.  One thing that the panel mentioned is that it is beneficial to do some team building at the start of a project.  This involves the local team and the offshore team meeting in-person for several days to get to know each other personally and begin to build relationships.  This is important for establishing trust at the start of a project.  Second, it is ideal to have a team member working locally who speaks the same native language as the offshore team.  This enables a better line of communication between the two offices.  Next, it is important to consider the scope and goals of the project, and then choose whether agile or waterfall development would be most appropriate.  Using agile can be more difficult when used among offshore teams, but if this approach is chosen, the use of video conferencing, source code management, and agile development tools can make things easier.

The Unconference

Lately, the “unconference” has been gaining market share.  Let’s do a quick review of how it differs from a traditional conference.

Typically, the traditional conference will have a roster of speakers from the relevant industry who will talk about the conference subject.  The speakers will either give prepared presentations, or speak in a panel with a moderator.  This model has worked for a long time, and it is still popular today.  The advantage of this model is that the attendees know in advance who the speakers will be and what they will discuss.  Therefore, attendees will often attend based on interest in a particular topic and/or speaker, but they might be less interested in the other topics and speakers.  Sometimes, traditional conferences are quite expensive due to the high-profile speakers that are recruited.

Now let’s see what an unconference looks like.  The unconference is similar to a traditional conference in that it has a theme and a number of speakers who speak on various topics related to the theme.  However, the unconference is more grass roots.  Typically, several people will stand up at the start of the conference and give a quick elevator pitch about what they want to do a session on.  Based on those pitches, the unconference attendees vote on who will do sessions.  And here we get to the crux of why the unconference is so unique…

Typically, no one knows which speakers will end up leading sessions until the conference actually begins.  Therefore the un-conference is by nature an event where the content is generated by the attendees.  Often this means that the content turns out to be more relevant to more of the attendees.  Usually everyone at the unconference is a volunteer, so the conference can be done at very low cost.

A possible downside of the unconference is that they can be a bit more chaotic than a traditional conference.  However, I find that this can be overcome if the unconference leaders display good leadership to bring some order.

As you can see, the unconference has some attractive attributes.  It is created entirely by the attendees, so the content can turn out to be very relevant to a majority of the attendees.  It can also be much less expensive than a traditional conference.  The unconference should continue to gain popularity and market share in the years to come.

Socialize your ideas early

This post discusses the difficult task of presenting business proposals to decision makers.  A typical example is when a product manager presents a business case to management, with the goal of shifting a product strategy.  This need often arises due to a change in market conditions, new feedback from key customers, or the desire to re-invigorate an ailing product line.  In any case, the significance of this type of proposal is that it requests management to move scarce R&D budget resources from one place to another, something that is never taken lightly.

In the above scenarios, one would like to have the highest probability of success.  In my experience, the way to have the absolute lowest probability of success is to walk into a presentation with very little prior discussion with the audience, and present the slides. This is what I like to call presenting “cold”.   Any proposal developed in isolation will likely not be received well.

First, it is just human nature that people do not like surprises when it involves serious matters such as how one makes a living.  If the product manager presents some brand-new ideas “cold” to an audience, the ideas are essentially surprises because the audience is hearing the ideas for the first time.  This means that the audience needs to pay close attention just to try to grasp the main points.  In a span of twenty minutes, they need to digest the ideas and form opinions on them.  And because they feel surprised, the audience members’ defense mechanisms kick in.  Even worse, the audience might not completely understand the proposal in the short amount of time that it is presented.  And when someone does not understand, they are much less likely to accept it.  Second, the audience wonders, “What do my peers or managers think about these ideas?”  If they are not sure if anyone else is on board, they will be much less likely to stick out their necks and give approval.  We need to keep in mind that because important decisions are being made, the audience knows that their jobs and reputations are on the line.  It is much less risky for them to retain the status quo.

Instead, it is always better to present “warm”.  In short, presenting “warm” is the process of socializing the key ideas with the decision makers in the audience in advance of the presentation.  The further in advance, the better.  This is typically done through informal discussions with one or two people at a time.  By doing this, when one presents the actual presentation the audience already knows what will be said.  In other words, the presentation is essentially a dry run of slides that the audience has already seen, and the meeting becomes more of a formality.   The audience is relaxed, can joke around, and the meeting goes much more smoothly.

The pre-socialization process works for a few key reasons.   First, the audience has time to digest the proposal and sleep on it.  This allows the new ideas to set-in and gives the audience more time to reflect on the pros and cons.  If they have no major objections, they have time to become comfortable with the new ideas.  Second, pre-socialization gives the audience the chance to bounce the ideas off of their peers and managers.  If there are no major objections from the peers and managers, it becomes much easier for the audience to accept the ideas.  In effect, the risk that the audience takes by approving a proposal is greatly reduced.  Third, by pre-socializing the ideas the presenter has the chance to obtain feedback on the ideas in advance of the presentation.  This allows the presenter to work any kinks out of the proposal and refine it to be more compelling.  Again, the further in advance that this is done, the more refined the proposal will become.  Keep in mind that the goal is to obtain prior feedback from the same people who will be approving it, so when the official presentation rolls around any major objections should already have been raised.

Just remember, always present “warm”, not “cold”.  The decision makers will appreciate it and the presenter can walk into the room with much more confidence, opening the door for a much higher chance of success.

Agile Bazaar – July 2010

At the latest Agile Bazaar, David Hussman spoke about, “Products and People over Process and Dogma.”  It’s a great title for a talk, and it is a good snapshot of what David conveyed.  One of the main points that David made was that agile development methodologies are not one-size-fits-all.  A set of processes that works well for one company might not work well for another.  Instead, the set of processes must fit a particular organization, culture, people, products, and customers.

The best part about David’s talk is that it really challenged us to question what an organization is trying to achieve with a given project and how agile development processes should be structured to reflect each unique project.  On the one hand you might have a large financial institution that is developing software to be rolled out to thousands of users.  On the other hand, you might have a small startup that is developing an application to be beta-tested by a handful of new customers.  We can quickly see that the right processes depend entirely on what the particular project is trying to achieve.  In agile development, these differences in process could include how the user stories are collected, the story-mapping process, the length of development sprints, etc.

Related to the point above, David recommended thinking about each new project as if it were a new startup company.  This means that it is important to question at the outset how much time to invest in process versus creating product, regardless of how a previous project was conducted.  For example, many organizations are under tremendous pressure to starting doing something.  This means that they start writing code, but this might not be the right step at a particular moment.  As a consequence, a lot of code is thrown out and needs to be re-written.  We can see that the question of when to start the agile iteration process is not an easy one and can be different for each new project.

Another great point that David made is the distinction between complicated and complex in software development. Software can be complicated, meaning that it can solve a difficult but clearly defined problem.  However, the users who use the software are complex, meaning that they do unpredictable things.  Doing a good job of translating user stories can help make this latter part (the unpredictability of users) easier.  And from this point we can see why agile methodologies have become so popular.  That is, agile is all about adapting to unpredictable users and changing business requirements.

To boil it down, David was trying to challenge us to think less rigidly when starting a new software project and trying to implement a set of development processes.  Think beyond the mechanics.  The how (what processes an organization uses) very much depends on the why (what they are trying to achieve).