I was planning to spend this morning working on a talk I’m giving in January, but as I skimmed through my RSS reader, I saw that Seth Godin just put together a book containing the ideas of several dozen insightful thinkers, so I decided to read this instead. It’s a free e-book called “What Matters Now”. You can find it here.
As I was reading through this, I remembered coming across many of these people in other contexts. I bought Steven Pressfield’s “The War of Art” at Powell’s Books in Portland. I first saw Hugh MacLeod’s work at changethis.com in an e-book called “How to Be Creative“. Some of their ideas are new (to me), a few summarize books or posts, some express what’s been learned over a career, others offer an opinion or a key insight.
One of the overarching themes of the project is that if you give something of value to the community or the world, you’ll get more back. If you’re someone like Seth Godin, this will come easily to you. For everyone else, I think it’s more of a challenge. I like Steven Pressfield’s comment here:
“I must confess that so far the only part I’ve mastered is giving it away.”
I haven’t really tried this yet. But I will now. I think I’ll start by putting my talk up on SlideShare. I’ll let you know where it is when I’m done.
BTW: If you’re in Silicon Valley on January 7, and would like to see my “value-based scheduling” talk, I’d be happy to meet you!
A friend of ours, James McIntyre, is a B2B technical marketer and one of the stars at McClenahan Bruer Communications in Portland. A while back I asked his advice on what I should do in terms of marketing my product. The first thing he said was to put a positioning matrix together. I looked confused; he elaborated.
What is a Positioning Matrix?
A positioning matrix is a document that helps organize your thoughts on how to describe your product (or service) to a particular type of person in a particular market. Whenever you communicate to your market (via a website, e-mail, presentation, sales call, etc.), your positioning matrix can help ensure that your message is consistent and focused.
Parts of a Positioning Matrix
I don’t think there’s a standard form for this, but what we’re using has the following structure:
- A column for each type of customer/user in your market
- A Vision Statement row cutting across all users that summarizes the overall product message
- For each type of customer/user, a positioning statement describing your product
- Value Statements that answer “What’s in it for me?” for each type of person
- Differentiators that answer “How is this different from other products?” for each type of person
- Sound bites that should strike a chord for each type of person in your market
- A 50 word statement describing the product/service
- A 100 word statement describing the product/service
Using a Positioning Matrix
To give you a better idea of what a positioning matrix is and how to use it, I’ve posted my company’s matrix here: Lakeway’s Positioning Matrix.
One place where this has already proven valuable was in the redesign of my company’s website. It helped focus our message, especially as we developed the Flash movie on our homepage. If you’re curious, take a look at the movie, compare to our positioning matrix and feel free to let me know what you think.
Composing a Positioning Matrix
It takes a lot of thought, reflection and feedback to draft a meaningful positioning matrix. The company where James McIntyre works offers this as one of their services. If you’re starting out and have funding, I recommend you check them out.
If you’re bootstrapping (as I am), this may not be an option, so roll up your sleeves, block out some time, brew some tea, and start thinking about why your company exists, what it does for your customers, and how it’s different from everything else out there…and make sure you revise it after you start talking to your market!
Last week, I gave a 2-day workshop on project management. I focused on what I call the Five Principles for Project Success. It’s been my experience that when any of these principles are violated, a project is headed for trouble. Conversely, if a project is in trouble, reviewing these principles is critical for recovery.
Everyone involved in a project at every level should always know the project purpose: who cares about a project and why is it important. People should know the project drivers (e.g., cost, quality, target date, feature set, stability, usability, performance, flexibility, accessibility, …) and how the drivers are ranked. This is the only way to rationally make tradeoffs within and across projects.
The project purpose is frequently overlooked because we tend to focus on the work that needs to be done and often get started on it without asking why. When this happens, we tend to work on tasks we want to work on, not necessarily what’s most important for the client/customer and stakeholders. We don’t move the project in the right direction, if in any direction at all. There’ll be plenty of motion, but not much progress. At some point (when the budget or schedule gets tight), we’ll have an emergency meeting to figure out what should be done and finally the project purpose will be recollected or even spelled out for the first time. Great, but too late. There won’t be room to recover.
The project purpose should be defined up front, and, again, everyone should know it. The purpose should be captured in something like a “Project Charter”. Johanna Rothman describes these charters in her book Manage It!.
The most famous quote on planning is probably from Eisenhower: “Plans are worthless, but planning is everything”. Ike said it in the midst of the Cold War, but it’s a timeless observation. When engaged in planning, we’re considering options. We think through risks and how we might address them. We lay things out, we make assumptions, we make choices. At the end of this we have a plan. However, no matter how thorough our plan or how much thought we’ve put into it, the plan can only reflect what we know at a given point in time. Things change. We may run into a set of unanticipated problems or perhaps the risks we did consider didn’t really have the impact we feared. When this happens, we should adjust the plan. We should re-plan.
Without planning, projects will be left to chance. Risks will come as a surprise and quickly derail a project. People will be constantly shooting from the hip, making decisions based on urgency instead of value, reacting to events instead of anticipating them.
Planning is something we should do throughout a project. When a plan is no longer useful, we should draft a new one. The plan itself is only a snapshot of what we knew at a point in time.
To make rational decisions about projects, you need to track project data. Period. This isn’t something you get from chatting with someone. When you ask “How are things going?”, you’ll get a response like “Pretty good. I think we’re going to be done with this next phase soon”. What does that mean? What does that tell you? When someone says something like that, I hear “We’re not done yet”. You need a finer level of status than that. You should be able to answer questions like this at any point during a project:
- Is the project running late? By how much?
- Is the project over budget? By how much?
- Which tasks can be started now? Are any of them late off the bat?
- Is the project resource-bound? Where are the bottlenecks
- What are people working on?
If you don’t have tracking, you won’t know if your projects are in trouble until the end. Key decisions will be delayed. Teams will miss important dates. The sense of urgency that should have come earlier in the project will come too late.
Tracking project data can be straightforward and easy if you have the right tools. If you set up your projects efficiently, tracking them basically boils down to logging effort left and effort spent. It can be that simple (with the right tools :-)).
Demos are the real measure of progress. If you can show something working, then you’ve actually done something. If you can’t demo anything, then you really don’t have anything of value. Demos are great because they expose assumptions. They ensure that details are looked after. They get everyone on the same page, something especially important when there are several teams involved.
If you don’t do demos, teams that can work separately will — and they’ll work in isolation. Work won’t be integrated until the very end of the project. Everyone will feel their part is on track when, in reality, much of the work is yet to come. When integration finally does arrive, it will take much longer than everyone expects. There will be unanticipated rework, cost, and stress.
Demos are something we should always plan for in our projects. They can be fun. They give people a sneak peek at something that no one else has ever seen. It’s a time for teams to get together and show off, when executives get to drop by and see progress, a time to re-sync before moving forward again.
Consistency is about predictable execution. It’s about dispatching work efficiently and having clean handoffs across teams. When you have consistency, your organization runs like a well-oiled machine. This can only happen when roles and responsibilities are clear, when processes are well-defined, and when people have the skillsets to play their roles.
If you don’t have consistency, you’ll waste a lot of time reinventing process on the fly. Tasks will be dropped, especially across team boundaries. There will be gaps in process, gaps in task assignments, and gaps in skillsets. Execution will stall and be unpredictable.
To become consistent you need to think through your processes and capture them in some form. Swimlane charts are a good tool to use here because they force you to think not only about what needs to be done, but also who should be responsible for it and what sequence the work should follow. It can be an interesting exercise to get people together to sketch out a process because it will quickly become obvious that everyone had a slightly different view of the roles and responsibilities. Getting clarity around this early-on improves consistency of execution.
These are the principles that I’ve found to be crucial for project success. Time and time again, these are what I point to when projects go wrong. Of course, there are other principles “embedded” in these five (e.g., communication runs through everything above). If you can think of a principle not covered above, please feel free to comment!