Hidden Stuff in Your Halo
I love the concept of the product halo. Essentially, a “halo” consists of all the items that actually go into making sure your product is a product / complete solution as opposed to just code, or some widget. In my mind, widgets are not products — the “product” is the widget + all the other stuff that goes around it. But, I digress.
Anyway — I was just working on a product strategy document, and realized something. Your halo does not only consist of things that are right in the customers face. A good example would be documentation - it’s key to the halo, and pretty up-front in terms of customer interaction.
There are plenty of little things that flesh out a halo, like the feedback loop.
If you truly are market driven, the halo must consist with ways in which your market segments can get their feedback to you so it can be taken into account, and ultimately acted upon when key things reach a critical mass.
I just wanted to get this thought down; it might not make any sense, but hey - what else are blogs for if not writing down thoughts that don’t make any sense.
How to Write Benefits
There is a great post from a while back on Roger Cauvin’s blog about benefits and communicating them effectively.
I’m currently going through a very similar process to what is mentioned here. I’m writing feature sets that will be incorporated into our product data sheets by our Technical Writer, Monica.
Now, I’m at a point where I’m getting into the nitty gritty details of these products I’m working with. Yes, I’m seven months in, and no, I’m not moving slow by any means — this stuff takes solid time. But, I digress.
In order to make sure that the product is being communicated effectively, a couple of key things have to be recognized:
1. You need standards
I don’t care who you are. It’s a lesson I learned early on, and one that will stick with me for the rest of my career. When you are managing product(s), you NEED to work to standards. Out-of-the-box, what’s in the package, post-shrinkwrap, whatever you want to call it. This becomes painfully clear when you have product literature and MarCom not speaking the same language.
Get on the bandwagon and make sure you are working towards standard messaging, a standard release checklist, etc… It builds expectation in the company that yes, training will happen, yes, these types of documents will be available, etc…
2. Writing feature sets is tricky
Make sure that you have a clear picture of what your lead-off feature will be. I like to group features, myself. I find it much more effective to have 4-5 features under a single heading, than creating a list of 27 features that all seem wayward. It’s hard on the eyes, and doesn’t get the value proposition of the product across to anyone reading the thing clearly enough.
3. Creating diagrams is tricky
If you manage software products, inevitably, you are going to come across a little tool called Visio. Make sure that you are rolling out standardized product architecture / flowchart diagrams to all product collateral. The last thing you want is a business stakeholder using different terms when talking to his tech folks about your stuff. Bad news bears. Try to make it as clear and concise as possible, while at the same time, sticking to the key features / value prop of the product itself.
4. Writing benefits is odd
Yes, odd. This brings my to my original linking to Roger’s post on writing benefits. The slide shown there communicates it perfectly. Practice, and make sure you have it right. Chances are, Sales will use the benefits as good talking points / lead-ins during their cycle to get buy-in. Features are important too, but some stakeholders may just pass them over as bullshit & fluff.
At the end of the day, the message has to come from everyone’s mouth in similar terminology and language. Product assets all have to communicate that, which means it needs to be deeply routed in your original product foundations.
Backpack
I want to point out how important Backpack has become for my day-to-day management of an array of products.
I’ve got a paid account, and create pages here for all of the products I currently manage. I’m sharing pages with the people in the company that need to see them, and I’m adding task lists, important documents, and making full use of writeboards to create roadmaps, feature & benefit sets, and so on.
No, it’s not a true Project Management tool like Basecamp. But, I’ve used Basecamp, and tried to get people to use Basecamp properly, but not with much success. I’ve already had plenty of success with Backpack, and thus far, everyone seems to be really into it.
One other great thing that I have taken advantage of is the unique e-mail address assigned to each page you create. I’ve got these added into my Outlook contacts list, and whenever I get my hands on a feature idea, or something that’s related to any of the products, I just forward it over to the page, and it automatically appears. How cool is that? It’s coming in really handy when I have to review market data and research points brought up by others in the company.
It’s a fantastic tool, and while 37Signals doesn’t mention Product Management as one of it’s intended purposes, I think they should add it to the list.
The Joys of Pricing
I like pricing things.
I think the biggest reason for this is because I know the cost of a product so intimately once I’ve done it. There’s no way I’ll ever be in a scenario where a prospect can stump me on the price. Once you’ve handled something for a while in a ton of detail, you get to know it pretty well. Especially when it’s all your idea.
Of course, the downside to this is, if the product never sells, you’re the fall guy.
I’ve come to learn that that’s OK. There’s no reason to shy away from being that fall guy. You can play that part effectively, so long as you are staying in tune with what the market is asking for. Don’t ever let yourself slip out of touch - it becomes tough to gather the trust back of those going to you for answers about what to do.
This doesn’t only apply to pricing - it also applies to other scenarios within product mgmt. Documentation, for example. If you write the docs, or come up with the “standard” doc set that gets rolled across all products, it’s pretty easy to remember exactly what’s available for use.
So, what’s the tough part here? Well, the functionality. I find that because I didn’t code the thing, I sometimes have a hard time remember everything, exactly. I’m not saying I forget how a product works - but there are certain things that I find take me longer to get into my thick head, because I wasn’t the run writing the actual code that’s driving them.
So, I guess I’m saying it all relates. When you price a product, you remember a lot better because you know the reasons behind why you priced it the way you did. When you code a feature, you know exactly why and how to justify coding that thing, and every foreach and if statement.
One thing I’ve found to help me out is a) think about the technology driving the product a lot b) think about the product a lot and c) review and talk and ask questions a lot.
In combination, I’ve found to be able to learn new products / technology quite quickly so I can start actually managing them and coming up with ways to sell or market them, and build upon new ideas.
Happy Friday!
Congrats to Happy Cog!
Just wanted to give a nod to Jeffrey Zeldman and the expansion of Happy Cog.
I do admit that I kinda feel like a fan-boy. Back in the days of starting to get into Web Development (and design, to some extent), I started reading The Daily Report on, well, a daily basis. After realizing that the Web was where I wanted to spend all of my professional / career time, I really turned to all of the great things and content Jeffrey had created for guidance - as I’m sure a lot of those in Web design / development have and continue to do.
In fact, I remember the day the Happy Cog site was launched.
Kudos, guys. You have done, and will continue to do, stellar work, and help lead us to outstanding online destinations that actually worry about the user - not convoluted interfaces that make me queasy.
