Solutions Engineering and Technical Marketing Plans

I found this in my "notes" on my iPad, I thought it might be useful to someone, so I present it here mostly un-edited. It's a simple list of the kind of things you should be thinking about when you're creating technical marketing plan for your solution or product :

Solution/Product/Feature Area

Describe the solution or product or feature that this plan covers. If this area has subcomponents list those subcomponents out and mark which one of those subcomponents will also have their own  plan.

Your Stakeholders

Who are they?

What are their concerns?

What does success look like to them?

How will you ensure their happiness?

Intended Audience

List out each audience type, example: field, partner, customer. Are there different deliverables for the different audiences?

Intended  Audience Behavior

For each audience type describe, specifically, what you want their intended action to be. Be specific. For example; "buy more product" is not appropriate. "reduce purchase barriers for the customer by showing the efficiency gains of X" is appropriate.

Value Proposition Demonstration

Elaborate the value proposition to the audience for each of the behaviors you want to drive. Tie the value of the product to the audience behavior. Describe how the solution or product demonstrates that value in such a way that the audience would change their behavior to seek that value. You want to be unique, compelling, differentiated.

"demonstrate the value of solution to a customer by showing the relative performance and storage efficiency gains of a system with and without X" is appropriate.

Technical Action Plan

The detailed technical actions required to set up and demonstrate the value proposition in a manner that it could be shared with the audience. This could be before and after configurations, performance benchmarks, etc. what will the lab look like, is gear available, need to be purchased?

Deliverables

List the deliverables that will tie all of the  above together. What supporting materials do you need? Do you have all of them in place to act as references? 

Field activities and events

Develop a plan for the field activities or events that will allow you to share the deliverables in front of the audiences, drive the solution, product, feature adoption: videos, webinars, conference presentations, user groups, sales support.

Too big to Dell?

The Dell-EMC deal is going to be the biggest the IT industry has ever seen. Five initial thoughts on the combination of the two companies and what we're likely to see as a result: 

1. EMC already has problems with too many product lines that overlap. This merger will make it worse. Expect a bloodbath. 
2. EMC has been trying to get into more compute, one assumes this is because of a recognition of software-defined-everything in the cloud and hybrid cloud. Dell has compute, there's obvious potential there. 
3. Storage margins are not compute margins. Because of this the two companies are structured very differently, EMC is a top-of-market company with best-in-class aspirations on all products. This is to drive high margins. Dell has historically focused on efficiency and made profits off of those efficiencies in low-margin segments. This deal gives Dell a better best-in-class story with higher margins by selling through the EMC brand. This gives EMC products a better down-market product opportunity by selling through the Dell brand without cannibalizing their best-in-class products. 
4. Pathways and relationships mean a lot. EMC might have been struggling some lately, but they are placed very well in large enterprises as the "trusted advisor" vendors want to be. They sell well into the c-level and have better golf course sales than almost any other vendor. Their sales force can pull Dell up into those discussions. 
5. vmware might have a time of reckoning. They have the focus of a company that grew too fast and didn't have any evolutionary pressure for most of its growth, they were alone in the market too long to grow tough. This deal could create much more aggressive board-level influence on vmware's product and design focus, or force them to mature out of a growth mode that pursues acquisitions and new products in a willy-nilly fashion. 

 OK - that's what I have in the fifteen minutes I set aside to write this. Thoughts welcome in the comments. 

 --paul

10 Behaviors for Success in a Product Escalation

If you have been around the IT industry for long, you've been involved in at least one big, gnarly escalation. Whether it's hardware, software, a service or product, something at some point will not go right and you'll be called upon to get things back on track. Following below are 10 behaviors that, when adopted, will make you and your organization look professional and earn trust while you search for resolution to the problem.

1. Confidence

You have to have confidence in yourself and your product. You have an initial budget of only so much trust, you can lose trust before you take a single action by seeming unconfident in your own or your product's capability.

2. Have a Plan

The best plans are simple to understand and communicate, and flexible enough to bend without having to start over. Identify actions, assign people, stay on track.

3. Take it Serious

This might be another workday to you, it could be the career of the people on the other end of the line. Act like it.

4. Enjoy It

You are in this situation because of a skill set or capability that makes you special. This situation requires concentrated competence, you've worked hard to get to this level, enjoy the fact that you get to showcase your skills.

5. Stay on Message and Remain Polite

You are here to help, you know how to fix the problem, the product will work or we will figure out a workaround. Keep reminding people of that. It seems that someone always wants to derail the situation and start assigning blame, staying on message keeps them at bay. Being polite while you do it keeps it professional.

6. Identify and Question Assumptions

Just because there are a lot of people involved doesn't mean all of the issues have been covered. Stop, review how the situation occurred, what's taken place since it started and then request and evaluate the data. 

7. Be Fact Based

When you remove the assumptions, move forward with facts. Test theories within your plan that are based on facts and that will generate new factual evidence. 

8. Set Priorities and Focus

You are trying to determine the first order effect that is causing the issue, the way to do that is through elimination. Attack the most likely issue first, even when it isn't the primary cause you eliminate a second order effect and reduce the list of possibilities.

9. Define the End Point Goal

What does success in this scenario look like? What is the desired outcome? It's surprising how often this is left defined as "better". This should be a hard metric like  "X things per second",  "Y milliseconds per operation", etc... You have to know what success look like.

10. Keep Track of What, How and Why

Most people will take notes, but not good ones. Take detailed notes, remember to add why actions were taken to avoid falling into the trap of repeating bad logic if something fails.

In addition to these 10 behaviors is the critical need to stick with it. Don't fall into the trap of shortcuts or desperate actions. Nothing will lose trust faster than long shot ideas. Once the issue is resolved, make sure you communicate why it occurred, how it was resolved, and how to avoid it in the future.