Inbound & Outbound marketing

Its nearly the end of the year, I’m about to close one Blog archive and start another - don’t worry, this means nothing for readers, its part of my admin. But it does mean that I put behind me all those half written blog posts, and single line ideas, that have been building up during the year.

Before I do so though, there are a couple of days to quickly get important backlogged entries out!

Two weeks I blogged, not for the first time, about Product Manager (Product Management an open secret, a differentiator). When I talk to people about Product Managers I often find myself in a conversation about marketing. Clued up people realise that good Product Management is, in part, a marketing function, others are surprised. They think marketing is about advertising and sales.

It is important, very important, to differentiate between the two sides of marketing: Inbound and outbound. So, for the record, I want to record it:

Outbound marketing: is the marketing most people think of when someone days “marketing.” This is about letting people know you, and your product, are here. Its advertising. Its public relations. It is generating sales leads. It is improving awareness. You get the picture?

It is called outbound because it is from you and your organisation to the wider world.

Inbound marketing: is from the wider world (customer, potential customer, competitors) to your company. It is about bringing that information inside and then acting on it. It is about building the products your customers want to buy. Get it right and sales should be like a knife through butter, people want your products.

In software companies, and other tech companies inbound is largely the role of Product Management. Product Marketing is about outbound. Although Product Manager is the usual job title some places call this role an Architect, others Programme Manager, and occasionally Project Manager. More often or not it is just absent.

Most companies realise, sooner or later, that outbound marketing is needed. Unfortunately, in all too many companies inbound marketing does not exist. Or inbound is “what the sales guy says the customer wants.”

As much as we love sales people (after all, they bring in the stuff that pays us) they are not the best people to decide what goes into a product. The reason why they are good at selling is that they get over customer objections and sell the product. This means the customer, the next customer, the next sale, is king. What the next customer wants isn’t what every customer wants.

Lets make this simple: if you are running a software product company and you don’t have a Product Manager then get one.

ACCU 2011 Conference registration open - beat the VAT rise

Just in time for Christmas, that special present for someone you love...

Buy them a place at the ACCU Conference in April.

If you live in the EU you have an very special reason to buy in the next few days: the UK is increasing the VAT rate so the price is going up on 1 January.

If you really want to save money, and you are not already an ACCU member then join the ACCU now, and immediately book the conference. It is cheaper, honest; no, its not an accident, it is meant to be like this.

I’ll be there, in fact I’m speaking, I have two sessions, one on requirements and one on patterns.

(Twitter tag for this is #accu2011)

Dialogue sheets, retrospectives and quotes (Send me your quotes)

Know any good quote about software development? Agile? Lean? Teams? Code? or anything else in this space?

I’m working on a little project and I need some though provoking quotes so please send them over - leave a comment here, e-mail me (allan at allankelly.net) or Twitter me (allankellynet).

Why?

Well, I’m working on a little project for retrospectives I’ve been dreaming of for a few year and I need some thought provoking quotes.

There are two problem I see with retrospectives - OK, there are other problems but there are two I think I can do something about. (And none of these problems undermine the reason for doing retrospectives or the value, just fly-in-the-ointment stuff.)

Firstly, retrospectives need a facilitator. That might not sound like a problem but ideally you want the facilitator to be a) experienced, b) impartial, c) available. Sometimes its not easy to find that person.

Second, I hear of teams who hold regular retrospectives but the retrospectives because boring, they go over the same ground again and again. To be effective, to get new insights they need jazzing up once in a while.

One way to resolve both problems is to use an outside facilitator once in a while but that needs organization and, most likely, money.

So, what if you could have a retrospective without a facilitator?

Over the last few years I’ve been experimenting with a technique called a Dialogue Sheet. Both in training and conference sessions I’ve used this to facilitate discussion. For more about dialogue sheets see my website with examples from XP Day, SPA and “Lean into Action” at the Agile Lean Exchange last month.

Now I’m working on a Retrospective Dialogue sheet. The idea is a team us this for a facilitator-less retrospective.

I hope to have the sheet ready by New Year and then I’ll be looking for some guinea pigs...

And the quotes: these get placed around the dialogue sheet to provoke thought and reflection.

When I’ve got this working I hope to allow you to download these sheets from my website or order printed versions directly.

Product Management an open secret, a differentiator

At the Skills Matter Agile Lean Kanban exchange the other week someone - sorry I missed you name - told me about a report from the BBC on Product Management. It turns out the report is from a branch of the BBC I didn’t know about, “BBC Academy” and it entitled “The State of Product Management 2010.” Its well worth reading if you have an interest in Product Management or the UK software development scene.

Although I’ve not blogged about it for a while Product Management is one of my passions.

Think of the development team as the beating heart of the work effort. Someone has to keep the blood flowing, someone has to keep the arteries clear and make sure the right requests for work can channelled to the development team.

This is a role. Someone needs to do this. Someone needs to understand customers and be in a position to prioritise. And someone needs to be able to have ongoing conversations with customers, developers and everyone else.

This is not a document, attempts to do this with a document makes things worse. Documents don’t have conversations. Documents are static.

One of the reason why Silicon Valley companies are so successful is that they understand this. In Silicon Valley there is a well developed role called the Product Manager. This is the person who looks at the customers, understands their problems and needs, looks at the market and a whole bunch of other stuff, and this person decides what is needed for a successful software product.

I point to Silicon Valley because certainly in Europe, and I suspect in much of the rest of the USA, this role isn’t so widely recognised.

This role doesn’t exist in corporate IT. Here the Product Manager’s cousin the Business Analyst fills a similar role but in a very different way. However, there is change afoot here, stay with me.

Here in the UK I find I have to explain this role to clients again and again. They make four common mistakes:

1. They assume the development team just know what is needed. Sometimes they do, sometimes they don’t. They may get luck once but can you rely on luck the second time? Third time?
2. They assume that the Project Manager knows. Again this is wrong, Project Manager training is about delivering a defined project to a date within constraints. It is not about understanding customers. (True there is overlap but Project Managers training is different.)
3. Experience IT Managers see the need and appoint a Business Analysts. This is the right thing to do when you are a corporate IT department, or if you are writing bespoke software for one customer but, if you are trying to create a product to sell to many customers it is the wrong choice.
4. Managers assume it is obvious, or that they, the “managers” know. If they are Product Managers or have been Product Manager they might be right. Even if they do know what the customers want someone has to explain it to developers and be on hand to answer their questions. Senior Managers just don’t have the time.

So its good to see the BBC highlighting this role. The description in this report is very media centric but it is recognisably the Silicon Valley Product Manager role. There are some good case studies in the report.

As I said, over in the corporate IT world this role doesn’t exist because customers are captive. One of the key aspects of the Product Manager role is understanding what customers (who have a choice) will pay for. In the corporate IT world this doesn’t exist: you get what you are given. So the BA role is similar but different. (There are other difference but they are for another day.)

(Interestingly several of the Product Managers quotes in the BBC report state they have Business Analysis backgrounds.)

The thing is: Business Analysts need to become more like Product Managers because more and more corporate IT departments are creating systems for external customers who do have a choice.

For example, 15 years ago just about all the IT created by travel companies was for their own use. Today travel companies have customer facing IT systems which can both win and loose the company sales. Online offerings are part of the buying experience, part of the customer experience and a potential product differentiator.

Even though the Product Manager role is not as well understood as it should be it is becoming more important. For those who get it Product Management is a potential differentiator.

Return to Requirements @ Skills Matter

I’m presenting a Skills Matter In the Brain Session this week, entitled “Return to Requirements.”

The key thing about this presentation is that it give a very very brief overview of the “Agile 10 Step” which is the model I use to discuss requirements in Agile work.

It is Tuesday 14 December, 6.30pm to be exact. Its free but you need to registration is required.

Salami Agile

More than one software development team has encountered the situation when the team want to be more “Agile”, the organization and management might even be asking them to be more “Agile” but, there are still many “requirements” in a big requirements document and the expectation is that all these will be “delivered.”

Ideally I would not set up and Agile development like this. Yes I’d set a few requirements to seed the first iteration but I would take a more goal directed approach. I’ve written about this elsewhere - see Time for Goal Directed Projects.

Basically Goal Directed means: the team have a goal, the team will determine what needs doing (requirements) and do it (implementation) as part of the same project. The team will be staffed with everyone they need to do both sides of the work (BAs, Developers, Testers, etc.) and will be judged by their success on reaching the goal. They will not be judged on how many features they implemented from some big initial set.

But, as I started by saying, some teams do have a shopping list of things they are expected to deliver and they will be judged on how many of those items are delivered and when.

So what do they do?

This is where Salami Agile comes along.

Think of the Big Requirements Document as an uncut piece of Salami. Someone on the team - preferably someone with Business Analysis skills but it could be a developer, project manager, or someone else - needs to slice the requirements into thin pieces of salami (story) for development.

There is no point in slicing the whole salami in one go. That would just turn a big requirements document into a big stack of development stories. The skill lies in determining which bits of the document are ready (ripe) for development, which bits are valuable, and which bits can be delivered independently.

Some slices of salami will need to be thicker than others but thats just the nature of the world. Over time, with more skill at slicing salami it will improve.

Ideally, the pieces of salami are delivered to the customer early, and over time they start to realise they don’t need some parts of the requirements document, some salami can be left unsliced and simply thrown away. Other pieces of salami will be cut and then thrown away. Thats not failure that’s reducing the work and is good.

And some requirements which were not though of can be easily incorporated. To stretch the analogy, you switch from German Salami to Danish Salami and back again if you so choose.

I imagine some readers will recognise this development approach, good. Now we have a name for it: Salami Agile.
(Picture from André Karwath on WikiCommons under Creative Commons Attribution-Share Alike 2.5 Generic license.)

Agile in Cornwall

As I’ve mentioned before, one of my current projects is to help companies in Cornwall adopt Agile software development. The programme is bring run under the Grow Cornwall umbrella by Oxford Innovation.

Next Thursday there are two open to everyone sessions to introduce Agile to companies in the Cornwall area and talk about the work we are doing.

If your interested you need to register at MeetUp - “Agile in Cornwall - Meet the Experts.”