Thinking about… Presales Career Paths

Where can I go after a role in Software Presales?

This has been a fairly common question over the years as I have interacted with team members and colleagues. The obvious answer is that Presales is the best job in the world, so there is no need to even consider a different role.

A more nuanced answer is that while there are some well-trodden paths to roles outside of Presales, often the available openings are limited. For many Presales professionals, their future Career Path is not clear or well defined. As a people manager, this can create challenges with how you develop and motivate your top performers.

I want to consider some of these paths further in future posts. For now, let’s briefly look at the Pros and Cons of the most common steps I have seen people take, both internal and external to a Presales career path.

Internal to Presales Career Steps

Solution Architect

Broaden your portfolio knowledge and move from a technical or product specialist to a solution generalist.

Pros: Logical progression for an experienced presales professional. Take the lead on complex opportunities and proposals. Is typically a more senior role within the team.

Cons: You become less hands-on with the technology.

Practice / Regional Lead

Different names in different organisations. A central leadership role as a subject matter expert. Set direction, enable others, assist where needed.

Pros: Gives you a leadership position while still retaining involvement in technical activites. Can raise your profile with product or other worldwide teams, giving you more direct links to senior people.

Cons: Can involve a lot of travel (at least pre-Covid) or calls at weird hours with peers and contacts in Americas or Europe. Openings for this type of role are limited.

Portfolio Change (at same or new company)

This is a fairly common step and a good one for giving you new things to learn. If you work for a large software vendor, there will be opportunities in other product portfolios or business units. Often Presales will take on a similar role at a new company – maybe in an adjacent solution space or maybe in something completely new.

Pros: Learn a new technology. Broaden your solution skills and experience. Good preparation and experience to set you for a solution architect or manager role. Lots of vendors in the market so usually plenty of job openings.

Cons: An internal sideways move may not increase your salary. Better pay is more likely if you move to a different company but applying for jobs can be time consuming and stressful.

Presales Manager

Become a people manager and lead a team of Presales professionals.

Pros: leadership role. Develop different skills and experience which can lead to future opportunities. Managers get more insights into business planning and can have more influence. Can provide deep personal and job satisfaction by sharing your expertise and developing others.

Cons: Only limited openings for such roles. Risk of losing contact with customers if all your time becomes internally focused. Managing people can be hard work and stressful.

External to Presales Career Steps

Sales Rep

Cross over to the dark side, pick up that bag and start selling. Show those annoying Sales People how it should be done. Presales often talk about taking this step but it may or may not pay off.

Pros: Can earn a lot more money. You have more control over the sales strategy. Presales can be extremely succesful as Sales Reps because they bring solution depth and credibility.

Cons: High stress and more pressure with less job security. Important to have a good mentor and/or good sales manager to help you transition.

Product Manager

Get more involved in the product direction and development.

Pros: Good way to utilise your solution expertise and customer-facing experience. Interact with many different teams and customers around the world.

Cons: Limited openings. May need to relocate and travel heavily. May need to take a pay cut.

Enablement / Training

Make use of your experience and teach others.

Pros: A great way to build on your expertise. Keeps you connected with the product while offering new activities and skills to learn.

Cons: Limited openings. Less technical hands on. May need to take a pay cut.

That’s a decent list for now. There are other steps and roles that a Software Presales team member may consider, including Value Consultant, Channel/Partner Sales, Chief Technologist supporting Alliances, or moving into Services Delivery or Sales.

The good news is that there are multiple career paths and options available for Presales. What can be challenging for an individual is to identify what interests them, where their passion is, and what their goals are.

What is your ideal next role after Presales?

Thinking about… Job Interviews

I’m currently hiring for several roles and have been conducting interviews. On Thursday I interviewed a guy (let’s call him Karl) who came across extremely well. In fact, he was a masterclass in getting the basics right. Karl had researched both me and my company, prepared insightful questions, and smoothly dropped a colleague’s name to establish a shared connection. It all served to build his credibility. What was a bit sad was how bad he made some of the other candidates look, without much effort.

Another good example I recently interviewed (we’ll call her Jane) was a former company employee. That gave her a clear advantage in terms of knowledge of our company and solutions, as well as a number of shared contacts. What I really liked about Jane was her active listening. I felt like she left the interview with a good understanding of the role and expectations, and that I had been listened to.

If you are a presales professional reading this, maybe looking for a new job, I hope this is a good reminder of some simple tips (although let’s face it, you can read about these things on any job hunting site). However, the message I’d like you to take away is that meeting a potential customer and presenting your solution is not that different to a job interview.

A customer meeting is an exploration of whether you (you personally, and your solution, and your company) are a good fit, and if it’s of mutual interest to take the conversation further. You want to make a good impression, form a connection with the customer, and progress to the next round. Preparation and engagement are critically important, whether it’s an interview or a sales pitch.

It is quite incredible to me that I’ve been interviewing people who seem to know nothing about the hiring company. It’s not hard to do a search or look up a corporate website. I’ve asked multiple people in interviews, “what are your thoughts on our company?”, and they don’t give any hints of knowledge. All I get are vague, general answers. Not even a mention of a product name. It makes them appear uninterested in the role and does not build confidence.

Karl, however, was different. He took the opportunity early in the interview to mention some references to products and a recent platform announcement. He related the portfolio area we were discussing to his experience. I was impressed. Not because of his knowledge of our solutions, but because he had clearly taken the time to prepare.

I do know that Karl had looked me up on LinkedIn. During the conversation, he made reference to “that’s when I worked with Sandy Doe”. Sandy is a current colleague of mine and a shared contact beteen me and Karl (I had also looked him up on LinkedIn). He didn’t make a big deal of it (as opposed to some people who will say “I looked you up (or even “I stalked you”) but I noticed, and I admired the way he used this to seamlessly build another connection point between us.

The second thing I noticed was that Karl was using notes. Notes that he referred to when demonstrating his knowledge of our business. And notes where he had written his prepared questions. As an interviewer, I don’t expect the individual to have a flawless memory, or even a deep knowledge of our company. Seeing the use of notes gave me confidence that Karl was prepared, thoughtful and organised. It also showed me that he was taking the interview seriously.

The last comment I’ll make about Karl is that he asked good, insightful questions. He had come prepared with a question written in his notes, and asked a pertinent question (about SaaS) that served to demonstrate his business acumen, and again reinforced the impression that he had done his research and would be a good fit for the role.

With Jane, the standout characteristic was her active listening. She listened, then restated and replayed her understanding of what I had said. She thought out loud about some of the implications, and the sort of actions she might need to take. I got a strong feeling that she undertood both the opportunities and potential challenges with the role. And as the interviewer, it made me feel like we had a connection. We were on the same wavelength. It was a great technique to observe. It was also a big contrast to some people I have interviewed, who talk and talk and talk. All they are listening for is the cue to start talking about themselves, rather than listening for the key words or concepts that I care about. Or trying to engage with me in intelligent conversation.

All the things I’ve mentioned above can be learnt and practiced. They are also simple to do. Before you go for a job interview, or a meeting with a new customer, make sure you:

  1. Go to the company website. Get familiar with their products and the language they use.
  2. Go to the company’s news / press release page. What are their recent announcements?
  3. Look up the individual you are meeting with on LinkedIn. What is their work history? Do you have shared contacts?
  4. Write some notes to help you remember what you have researched.
  5. Prepare 1 or 2 questions that demonstrate both the research and your business knowledge.

Whether you are applying for a job or pitching for a sale, your goal is to get invited back to the next meeting. Preparation and active listening is key to making a good impression.

What else do you do to prepare for an interview or meeting?

Thinking about… “It depends.”

Ah, the classic Presales (and consulting) answer to those key customer questions:

  • Where do we start?
  • How long will it take?
  • What will it cost?

“Well, it depends…”

I use this answer myself and see it getting used often by others in the team. I want to consider in this post why I think “it depends” can be a problematic answer, and offer some alternatives and expansions.

In summary, what I’ve concluded over time is that the customer is looking to me as the subject matter expert, and they are looking for guidance. The demo they’ve just seen looks great and exciting, but it also looks complex and feels a bit overwhelming. Therefore, I need to answer these questions in a way that gives them a better understanding of our solution, and a higher level of confidence in why they should choose to work with us.

A challenge for Presales with these sorts of questions is that “it depends” is the most truthful, accurate answer we can give. And if you are a detail-oriented technical person like me, accuracy and facts are important. You don’t want to mislead the customer, you don’t want to kill the opportunity by making it sound complex and expensive, you don’t want to anger the Sales Rep, and you probably don’t have enough information yet to provide a more specific answer.

The risk with answering “it depends” is that it can contribute to our solution being perceived as too complex, signals that we don’t understand the customer well enough, and puts the burden of analysis and decision making back on to the customer. Unfortunately, this helps our biggest competitor in every sales opportunity: Do Nothing.

One thing to remember is that the customer is asking genuine, curious questions. Just like a sales team, your customer is also engaged in discovery and qualification. Evaluating the products and messages from different vendors can be confusing, and they might be exploring a solution or technology that is unfamiliar. The customer is not trying to trap you or to get an answer they will hold you to. They are thinking about their own problems and plans, their ability to get budget and resources, and the expectations they have from management. These are important questions to help them determine whether your solution can meet their needs and how likely it is that they can proceed with a purchase and a project.

As the subject matter expert, what we in Presales need to do in this situation is provide a confident and clear answer, that expresses a point of view (POV). This is important for three reasons. The first is to provide the customer with the information they have asked for. The second reason is that you want to provide such information in a way that reflects well on (and hopefully differentiates) your company and solution. The third is that being able to provide a firm POV demonstrates your knowledge and experience – both of your solution and of the customer’s situation.

It’s a lot easier for a person to evaluate and respond to a stated position than to be faced with a large list of options and variables. Even if they disagree with you, or things change as planning progresses, your answer is giving the customer something tangible that they can consider and discuss. This provides focus, lightens their mental load and makes their job easier, which will also reflect well on you as the vendor.

Where do we start?

This is a common question, especially with solutions that can address multiple use cases or provide different capabilities. Is this situation, it’s great to reference other customers, and to talk about recommended best practice.

If you have done appropriate discovery with the customer, you should be able answer this question with some confidence. This is another reason why it is so important to talk to key stakeholders before a demo. And make sure you ask questions during the demo (and note the questions they ask you) to understand their requirements, pain points or areas of focus. You want to tailor your answer to “where do we start?” to align as closely as possible to the customer and to demonstrate that you understand them and their business.

Example answers:

“It depends on a few factors, including X, Y and Z. Let me give you some examples. At customer ABC, they chose to start [here] because of [reason].”

“Based on my understanding of your business and pain points, I would recommend that you start [here].”

“Best practice is to get quick wins by starting with [capability 1], then expanding to [capability 2].”

“There are three common starting points that our customers take: D, E, or F. From what I’ve heard today, I think you will get the most value by starting with E and then expanding.”

How long will it take?

“How long is a piece of string?”

This is an interesting one to answer, because there are so many variables. It’s also tricky because there is often a tension between the Sales & Presales team, who are trying to make their solution look easy and close a deal; and the Professional Services team, who have been burnt before by under-scoped projects, and have a good understanding of what it will “really” cost. Add in (unrealistic) customer expectations of fast time-to-value and the risk is that an “accurate” answer might not get you to the next round of discussion.

Variables that influence this answer include: the scope of the solution, the point you are at in the sales cycle, size of the organisation, size of the project team, complexity of the environment, how much of the work they want to do themselves, change management considerations, executive sponsorship etc.

My broad advice is to focus on breaking the answer down into quick wins and short phases that deliver value. What the customer is usually asking is, “how long will it take before our teams can start using this?” rather than “how long will it take to implement absolutely everything that is available?” You can also talk about concepts such as quick starts, sprints and minimum viable product (MVP) as ways to make the time-to-value sound shorter.

Example answers:

“We take an iterative approach and typically work in 3 month phases”

“Customer XYZ were up and running with out-of-the-box content in 6 weeks.”

“Our services team have a “Quick Start” approach that involves installation, training of your team and basic setup. This typically takes 2-3 months and then we handover to you.

What will it cost?

This is a difficult question. Not only are there multiple variables that impact the scope, there is list price, street price, and the price that the Sales Rep may be desperate enough to offer. Generally I expect that the Sales Rep will step in at this point to answer, but sometimes find the Sales Person is also looking at me expectantly, especially if they are new to the solution.

The most common and best way to deal with this question is to defer by saying that we’ll need to gather more information, take a look at it and get back to you with some rough pricing.

Sometimes I have thrown out a rough number, such as “the entry point is typically in the range of 100K”, although I feel uncomfortable doing this. I have seen Sales Reps also do this and one trick is to think of a likely number and then (at least) double it: “the entry point is typically in the range of 200-300K”. This puts a figure in the customers mind, and gives you room to come back with a more accurate figure. But it’s better to avoid this.

Where Presales should be direct and specific is in explaining the core mechanism and drivers of pricing. Use the time here to ask questions and gather the data you need in order to pull together some rough pricing. These might be number of users; number of agents; number of devices; volume of data; or whatever else is relevant to your software.

The corollary of this question is “What is it worth to you?”. I would not directly ask the customer this, but what I do is listen for ROI anecdotes or measurable evidence of the pain they are experiencing. And I ask questions that will help me build a value story. When we do come back to share pricing information with the customer, I want to do it in the context of the anticipated value that our solution will deliver.

In conclusion, when answering any question we are trying to build confidence in the customer. Using “it depends” is a valid (initial) response, as long as you immediately follow up with concrete information or examples that demonstrate your expertise and provide a clear and understandable point of view.

How long does it take to write a blog post? It depends…

Thinking about… Have we built a business case for our competitor?

Focusing on value, quantifying benefits and building a business case that shows positive Return on Investment (ROI) can have a great impact on a sales pursuit. I will regularly draft a business case analysis to use as a talking point with the customer. Walking key stakeholders through the value story can be a highly effective way of engaging customers, allowing you to uncover more insights about their business, goals, pain points and challenges.

The most common question I get asked by colleagues and customers about a busines case is: “where do these benefit figures come from?” I might consider that in another post, but a colleague recently asked me an interesting question that I want to explore:

Have we built a value proposition for our competitor?

It is true that the primary value of a software solution is often independent of the vendor. And this is especially true when there are obvious pain points that automation or improved visibility can address.

If I own a bicycle and am considering investing in a car, a key value driver will be time to destination (TTD). To get to work on my bike currently takes 45 minutes. With a car the journey will only take me 10 minutes, giving me a saving of 35 minutes every morning (78% improvement). However, assuming I must stick to the speed limit, whether I drive a Ford or a Hyundai to get to work, the 78% improvement in TTD is going to be the same.

The Hyundai dealer might spend hours with me to gather data and build a business case that clearly demonstrates the benefit of investing in a vehicle over a bicyclce. I become convinced that I need a car instead of my bike, because it will save me 233 hours per year. At a time value of $150 per hour (I’m worth it), I’ll be saving $34,950 each year, and that’s from only one use case. Awesome! However, the Hyundai dealer’s work and investment of time all goes to waste when I decide to buy the Ford instead.

Is this a risk for us as software vendors, if we build a ROI model during a competitive sale?

Hopefully you’re already thinking of the limitations in the above bicycle/car scenario, and what the Hyundai dealer should do.

From a benefit perspective, all our dealer has used and quantified in this analogy is a single value driver (Increase productivity by reducing Time to Destination) that is common to both solutions. What the Hyundai dealer needs to do is identify and focus on additional things that differentiate her offering from the competition. And even better if she can quantify the value of items that are unique to her vehicle. For example, an inbuilt GPS with unique AI technology could save time with route planning and by adjusting to traffic conditions. Or maybe the fuel consumption is a differentiator that will save money spent on petrol. Over 3-5 years this saving will add up and be substantial.

When building a business case in this vehicle scenario, Time to Destination (TTD) is still an important benefit to include, even if it’s not a competitive differentiator. Maybe I as the customer need to get my wife’s approval to invest in a car and must show her a strong business case. What the vendor (car dealer) needs to add to the value story are additional value drivers or benefit statements that play to their strength against the competition.

The other obvious variable that influences ROI is cost – the “Investment” part of ROI. This is something that a vendor has more control over, compared to the competition. If all the benefits are equal between two vendors, reducing the cost will make the ROI of your solution look better. However, the risk is that you end up in a competitive discounting situation, and the emphasis shifts from value to price. As a vendor, we don’t want this to happen. We are not selling a commodity and we want the perceived value to justify a price premium.

An important aspect here is to make sure you include the Total Cost of Ownership (TCO) over time as the Investment, not just the up front cost of your software or services. Maybe your solution is more expensive to purchase, but requires less cloud infrastructure or less internal staff to run. Maybe the consulting and upgrade costs give you an advantage. Using my car analogy, maybe the Toyota requires servicing every 6 months while the Hyundai only requires a service once per year, saving the buyer more money over time. Ongoing fuel costs could also be included here in the investment section, although its important to not double-count benefits if you’ve already shown them as a cost saving benefit.

In the end, we are trying to tell a Value Story that looks reasonable. We will adjust the levers of assumptions, benefits and costs to reflect that story, supported by customer discussions, case studies and other proof points. From a competitive standpoint, make sure you hone in on value propositions that will set you apart, regardless of the calculated benefit figure.

Another angle to consider is that collaboratively creating a business case is a great way to engage the customer and build a stronger relationship. Many of our buyers lack the experience and skills to build a business case analysis and are grateful for assistance, as they navigate their internal approval and procurement processes. Offering this help in a professional, transparent way can itself be a strong differentiator against the competition.

Having a platform/tool and a methodology for value analysis is extremely helpful in conveying a sense of professionalism. Some organisations have Value Consultants and Value Engineers who operate within a Value Management Office (VMO). There are also vendors who provide collaborative platforms and expert resources. If you have access to such people and tools, make sure to use them on your opportunities. Ask the customer if they would like help from your Value Consultants to build their internal business case.

It’s also beneficial for you as the vendor to engage the customer in the business case process, because you gain more insights and detailed information about the customer’s environment and challenges. Understanding their business goals, the real cost of their current situation and their pain points can help you tailor your proposal and presentations, potentially giving you another competitive advantage.

Also, if you can get the customer to spend time with you on the business case, then they are not spending that time with the competition. And simply by talking through the ROI model, validating and adjusting the figures with the customer, you are reinforcing messages about your company and the value of your solution. And the more time you can spend with the customer, working together, the stronger their confidence in you will become. So it’s a great thing to do.

In conclusion, I would never be scared of building an ROI model that could be used to justify investment in a competitor. Focus on what makes you different, ensure the investment covers TCO, and include the customer in a collaborative process.

Have you ever had a competitor co-opt your business case at a customer?

Thinking about… Presales Timesheets

Takeaway: Understanding what the team is doing and how they are spending their time is valuable, but I don’t think weekly time tracking is an effective approach for Presales.

I’ve had a particularly busy few weeks, working on multiple tasks, both internal and external, and wearing different hats of responsibility. I was feeling busy, stressed and under-valued. I got to a point on Thursday where I wrote a list of everything that had been consuming my time and attention for the past 10 days and sent it to my manager. It was a long list. I didn’t need immediate help, but I wanted my activities and contributions to be known and acknowledged.

My manager promptly replied with a short message, thanking me and also making a nice observation about how my workload is a reflection of people’s trust in me. He also followed up with suggestion on potentially moving one of my responsibilities to someone else. I appreciated his response and it helped me feel positive that my effort was recognised.

The topic of timesheets (or time tracking, or activity tracking) for Presales teams is one I have a close connection with, having spent many years as “management”, trying to get 100 Presales specialists across 9 countries to regularly track the time they spent on different activities. It was time consuming, frustrating, and in the end, I don’t think it was worth the effort. If I was to become a Presales Director again, I would not take the same approach.

The case for time tracking

The best specific example I have of time tracking adding value is a period where our Presales staff were spending a lot of time on post-sales technical support. While some level of post-sale engagement is normal (and desirable), the proportion of time was too high. By tracking time and activities, I had hard data and metrics I could use as evidence to escalate the issue to senior management and the support organisation. Graphs about trends and time breakdowns are more compelling than just anecdotal evidence.

For senior management, the attraction of tracking Presales activities and effort is to get that understanding of what people are doing, and to be able to track and report on KPIs about productivity, utilization and win rates. The VP or Director of Presales is expected to be in control of their team and such data can help with resource planning, justifying additional investment, or showcasing the contributions of the team.

Questions that you might want activity tracking data to help you answer include:

  • Are we spending time on the right things?
  • Are we working on the right customers and opportunities?
  • Are we doing too many POCs? Not enough demos? Too many unqualified tenders?
  • Are we winning deals when we do POCs?

Accurate time tracking can definitely provide Presales and Sales management with tangible data, to help make better strategic decisions.

For Presales team members, time tracking provides a way to give management visibility into what you are doing. If you are working 50 hours on a POC, or are juggling 10 opportunities at once, activity tracking provides a clear record. As noted in my introduction, such recognition can be important, whether its simply an acknowledgement of your contribution, or it helps lead to discussions about prioritisation, delegation or even compensation.

The case against time tracking

The biggest issue I have with time tracking is that the value of the data does not outweigh the effort required to collect accurate data. Presales staff are usually very busy and its easy to forget or choose not to record your time. If not enough of the team are filling in their timesheets, then the data you do have becomes less and less meaningul. If the data is not meaningful and statistically relevant, then why expend the effort?

I literally spent years reminding, reporting, auditing and chasing people. And I never succeeded in properly making it a consistent habit. Some people were very diligent while many others were not. Weekly compliance typically ranged from 50% to 75%. My time, and my teams’, could have been spent on more productive things.

For individual contributors and Presales staff, it can be very hard to see the value in time tracking. It feels like a time consuming imposition. It doesn’t seem to help or change anything. At the end of a busy week, it’s easy to forget and the last thing you want to do.

In my current role, as a manager and business consultant, I try to do the right thing and record my key activities. I’m not a fan of it but I believe it is important to be a good corporate citizen. However, I often forget, or I’m working on things for which there is no specific account or opportunity in the system, so the data I do record is an incomplete picture. When I was feeling overloaded last week, it was a lot easier and more satisfying to write a simple list in an email to my manager, and to speak to him, than to take the time to fill in a timesheet.

An alternative approach?

I have three suggestions for Presales managers who are considering timesheets, time tracking, activity tracking or an equivalent.

  1. Regular 1-on-1 meetings are important. Make sure you provide your team member time to update you on their recent activities and upcoming plans. It will keep you informed and provides them with important acknowledgment. A 30 minute discussion every week is much easier than filling in a timesheet, and provides greater value to both people.
  2. Focus your activity tracking only on POCs and RFPs. Given the time-consuming nature of a Proof of Concept/Proof of Value and a tender response, understanding how many your team are doing, whether they are well qualified, and if they lead to sales wins is important information. It could help you justify the need for more resources, or push back on sales teams. Instead of trying to track everything Presales are doing, put a process in place to monitor and track only key activities and outcomes.
  3. Perform a short Time/Activity Survey, every 6 or 12 months. Instead of weekly time tracking, ask staff to record their activities over a 2 week period. A good time for this is in your Q2, when kickoffs and breaks are over, the team is geting into busy mode, and before you get into detailed resource planning for the next year. Such a survey should provide sufficient information to guide planning and strategic discussions, without being an ongoing imposition on the team.

How do you get visibility into what Presales are doing?

Thinking about… Tender (RFP) responses

This week I am responding to two “evaluation” documents. As tenders go, these ones are relatively light, but they have reminded me of why I hate doing tender responses (and I’m not even doing most of the work!) The first document was a classic example of being sent through Friday morning, with a request for a response by Wednesday. I don’t know many sales teams who are sitting around with nothing to do, or that don’t have meetings typically booked 1 to 2 weeks ahead, yet tenders seem to invariably arrive at the last minute (and often just before a holiday period).

I’ll start with a rant to get things off my chest. Please feel free to skip the rant and scroll down to my 3 Guidelines for Tender Responses, where I focus on practical tips.

{Start Rant}

Tenders are a huge time sink, for both the customer and the vendors. For a start, they take a huge amount of effort for the customer to define their requirements and create all the documentation, and then more effort to go through the review and evaluation process. I’m pretty sure the staff working on the tender also have day jobs that demand their attention while this is going on. For vendors they are costly to respond to, involving multiple people who often work overtime to meet the short deadlines. There might be 3, 5 or even 10 vendors all working hard, with hope in their hearts, when in fact the customer already has a preferred vendor and are just “getting through the process”. So the ROI for doing tender responses is typically not great.  But as vendors, they are emotionally hard to ignore or to qualify out of.

After all that effort, tender documents can often end up as a laundry list of requirements given by different teams, rather than a strategic, cohesive document. This increases the effort taken to respond, makes it harder for the customer to properly evaluate and compare all the vendors, and is not realistic about the path forward. I have seen too many examples where the reality of implementation falls well short of the requirements that were evaluated. There may be 100 “mandatory” requirements listed in the tender, but 3 years later the customer is only using 5 core capabilities. And all the vendors that were evaluated could have delivered those 5. So why go through such a costly and difficult process?

The principle behind going to market might be admirable, but how many tenders really meet the objective of diligence and governance that they are meant to? As a vendor working with a prospect, we’ll always try to find ways to avoid a tender process. Perhaps by staying below a price threshold (most common) or building on an existing agreement. We’ll also offer to help create the requirements, in order to plant those items which will favor us.(and we want to get in there before our competitor does the same thing). I have also seen customer staff doing their best to get around or shortcut the process (while still working within the rules), because it slows things down and often does not change the outcome. All too often, the price ends up with the highest weighting in the evaluation criteria, which devalues all the effort that has gone into both creating and answering the detailed requirements.

The whole tender process is inefficient and the ROI is poor for both customers and vendors. It’s not just the labour cost of the effort expended by all parties. The longer it takes to do an evaluation and get started, the higher the cost of delay that is being incurred by the customer, which works against the benefits that will be delivered by the new solution.

You can validly ask at this point, “what I would do differently?” I do believe governance is important. Within any organization or process, it is critical to have checks and balances, and levels of approval and oversight related to spending decisions. However, after all the paperwork is done, I feel like purchasing decisions are typically made based on relationships, price and confidence that you can deliver. Yes there will be differences in features and functions between vendors, and they may take a different approach to solving a given problem, but broadly speaking vendors are usually offering similar capabilities that will meet the customer’s core needs.

The differentiators between products should be clear from a demo, a reference call and a discussion, without the need to write and score lots of detailed requirements. I’d prefer buyers to focus on a few “big rock” key capabilities that they evaluate, and to have them focus on the differentiators and exceptions in an interactive discussion with each vendor. A short 1-page checklist or scoring model that evaluators can complete and then compare should be sufficient, and would save everyone a lot of work and time.

{End Rant}

3 Guidelines for Tender Responses

Tenders are a fact of life when you are in Presales. So apart from ranting, what are some practical suggestions I can offer? Here are 3 guiding principles, with some tips for each.

  1. Don’t make the customer work hard
  2. Don’t be fully compliant
  3. Share the load, smartly

#1 Don’t Make the Customer Work Hard

  • Summarise your answer (and how you have interpreted the requirement) in a few sentences. Use bullet points
  • Crop and Zoom a screenshot to highlight a portion of the screen and make it readable
  • Screen shots can make you stand out. Even if they haven’t been asked for, add some in anyway to illustrate how you address a requirement. Use attractive screen shots only.
  • Make images big enough to see. Expand the size of the table or row if needed, rather than pasting a thumbprint-sized image
  • Use links to flyers or data sheets sparingly. If the detail is all in a public datasheet, I agree there is no sense in copying it all into the response document. However, it’s still important to summarize your answer before linking
  • Never ever link to an Instruction Manual, where the reader has to click a link, open a document, then search for the answer. Don’t do it! Simply provide a summary sentence to confirm that you address the requirement.

#2 Don’t be Fully Compliant

  • If you answer Yes to everything, the customer will be suspicious
  • If you answer “No” or “Partially” that builds credibility
  • The customer will spend more time reading the “Partially Complies” and “Does Not Comply” responses. Focus on answering these in more detail, and putting your spin on how you still address the business problem
  • Review compliance early, before adding the text answers. If you don’t comply with enough requirements, qualify out of the opportunity and avoid wasted effort (or maybe spend your effort on a simpler non-compliant response)
  • Requirements and Responses are both open to interpretation. Summarise your interpretation in the answer. Even if you have not answered the actual question that was asked, you have indicated why, and have an opportunity to reinforce a key message.

#3 Share the Load, smartly

  • Review solution fit and compliance early and discuss as a team. If needed, qualify out before expending additional effort
  • Assign roles within the team for each section (and even each question) of the response
  • Avoid emailing around document versions that can get out of sync. Use a shared document or collaboration tool (eg. OneDrive, Teams, Google Docs)
  • Turn on Track Changes in MS Word and get familiar with adding Review Comments
  • Hold regular checkpoints (every 1-3 days) to confirm progress, keep the team focused and identify any issues or gaps
  • Allow enough time for a final review and editing, and be clear on who is responsible for the final document

What are your top tips for responding to tenders?

Thinking about… Mentioning product names

Takeaways: Tailor your message to the audience. A product by itself is not a solution.

My first Presales manager would drum into us the refrain, “we sell solutions, not tools”. In the years since I’ve been involved in many similar discussions, trying to teach Sales and Presales to focus on value, outcomes or capabilities, rather than the products that are involved. But I have to admit, not mentioning the product name and not using words like “tool” is really hard to do. Especially when our training is usually on products, we price by product, and at some point the customer needs to install or login to one or more products.

This topic came up again recently in two separate discussions on the same day. First, I was talking with an experienced Sales Manager who is new to our company and was preparing for a CIO meeting. Through the discussion, it became clear that one of the traits of our team he had been observing (in both Sales and Presales) was an overuse of product names. His point of view was emphatic: “We should never mention product names”.

Later that day I had lunch with Presales colleagues, and the topic came up again. I can’t recall the full context but one of them fairly quickly made the point that “at the end of the day, we are selling a product”. It’s a viewpoint I have expressed myself, so it got me thinking. When is it ok to mention the product name?

My first conclusion is that what is most important is to tailor your message for the audience. This is true whether you are having a conversation, making a presentation, writing an article or demonstrating a product. If it’s a high level meeting with a CIO, talk about business outcomes and broad capabilities. If you are pitching a complex solution that involves multiple products, talk about the problem you are solving and the value you are delivering. If you are talking to a technical, knowledgeable buyer, then it might be better (and even required) to use the product name.

When talking to existing customers, I often present a slide showing general capabilities or a standard framework like IT4IT, then overlay it with product names. It helps make the connection between their existing tools and the solutions we want to talk about. I’ve also worked with products that have changed names multiple times and have been owned by different companies. Mentioning the old name is a good shortcut to get to a mutual understanding of what I am there to talk about.

The second thing I realized is that the selling/buying process has changed a lot since I started in Presales. Vendors typically get involved much later in the process, after the buyers have already done considerable online research. One of the consequences of this is that a technical buyer may approach you specifically about your product, and they may already have a fixed idea of what they are after. As my colleague John said at lunch, “They aren’t interested in your company or your other solutions, they specifically want to know how your ‘automation’ product compares against the other vendors they are considering”.

In such a situation, it can certainly be easiest to talk directly about the product. However, the requirement (and challenge) is for Presales to still do appropriate discovery and qualification about the problem, so that we can then position the right solution (which might be one or more products) and potentially expand the conversation. Try something like this: “Before I dive into talking about [Product X], can I ask a few questions to make sure I understand your situation and what you are looking for?”

One good reason to mention product names can be when you want the buyer to do further research online, or if you are going to send them a case study or analyst report. These are mostly aligned directly to product names and you might need to help the customer make the link from the solution you are proposing to the products referenced in the document. This can be especially useful if you are well positioned in an analyst report, have good brand recognition, or if you have an active and positive online community. (Of course, the reverse scenario might also be true, and you don’t want the customer looking up specific products!)

A third and very important consideration here is that a software product or tool by itself is not enough to deliver a solution. As vendors, we are fooling ourselves if we pitch a tool as a “solution”, without understanding, communicating (and costing) all the other activities that are required to get the software in production and being used effectively.

Delivering outcomes requires consulting, planning, design, implementation, configuration, integrations, training and change management. This is where services teams, partners and System Integrators are so important. The software itself may only be part of what contributes to a larger project, and the outcome may require multiple software tools working together.

(As a side note, one drawback of positioning a “solution” can be that if multiple tools are involved, the infrastructure cost can be huge. A SaaS service may help mitigate this issue, or you will need to identify areas of synergy, in order to redcuce the overall hardware footprint)

The final point I want to make is about the importance of having different roles in the sales team and assigning the right person to each conversation. We need Technical Presales who specialize in products, but when you have such deep focus it can be hard to step back and also play the role of a Solution Architect. Having a Solution Consultant or Enterprise Architect or Business Consultant type role within the Presales team can help address customer conversations with more senior people, or that are held earlier in the sales cycle. I have also seen great examples of collaboration with Solution Architects from Professional Services, who have the experience to contribute a broader solution focus to a sales pursuit. And as already mentioned, for a larger, more complex solution, a System Integrator (SI, or SIer as my Japanese colleagues say) may be required to lead the discussion on outcomes and help you sell a solution at a more senior level.

In conclusion, I do think its good practice to focus on the outcome being delivered, not the tools or products that will deliver the solution. Especially when you are talking to more senior people, when you are in early stages of discovery, or when you are proposing a solution that involves multiple components. It’s also a reality that we will need to show and talk about individual products, and that customers are often approaching us when already comparing different tools. I’ll try to talk about solutions and capabilities, but I’m not going to beat myself up for mentioning a product by name.

In the language you use today, are you selling products or solutions, tools or outcomes?

Thinking about… an awesome demo

What makes for a good demo delivery?

I don’t deliver demos very often these days, but I still get called upon at times to demonstrate our Project and Portfolio Management (PPM) solution, in which I have a lot of experience. I was pretty proud and pleased to receive the following feedback from the sales rep after a virtual presentation last year. And it’s a great summary of what went well.

From: [Sales Rep]
Subject: Presenting

We have discussed presentation skills many times in the past with the pre-sales team. Too often they are being trained the wrong way – to show the capabilities of the tool & not the benefits to the organization of using the tool.

Just listening to Matt today doing a PPM preso to [Customer] & I wish we all did more of it.

  • Does lots of name-dropping of other org’s using it & the benefit they are getting
  • Started with a teaser of what they would see in the whole preso
  • Gave an agenda which was about the benefits they would see in each part of the preso
  • Checked that everyone was on-board … and did it in such a way that they actually meaningfully engaged with feedback
  • Constantly talked about ways they could get business value from functionality
  • Question answering is masterful. Makes it sound like a great question. And answers it from a business perspective (with a tool demo backing that up)

The outcome was the best customer engagement that I have seen for a long time – & that was over Teams! Takes away the argument around customer interaction when doing it virtually!

If you have time to read on, let’s explore each of those points in a little more detail…

Does lots of name-dropping of other org’s using it & the benefit they are getting

A rule of thumb I was given once by Steve Capper is to mention two customer names every 30 minutes. It can be done by presenting a case study or reference as part of the presentation, or it can be done briefly in passing. When I’m talking about a capability or feature in a demo, I like to add colour by saying something like “This is how they used (or configured) this at customer X and it helps them with Y”.

Dropping names adds credibility to the fact that other customers are using the software and getting value from it. You don’t have to use the actual name and can always say “a large bank”, for example. To be honest, I take a bit more leeway when speaking and sometimes will use the name, or make it obvious who the customer is (“a large green bank based in Perth”).

The other thing I did deliberately in this instance was to reference a customer early in the presentation. Slide 1 (title slide) introduced the session; Slide 2 introduced the solution (see next point); Slide 3 introduced a customer value story. It wasn’t until Slide 4 that I got to the agenda and then a few positioning slides. My goal was to capture their interest and attention up front, and reassure them that our solution is mature, low risk, and used effectively by other similar customers.

One note to make is that in a prep call, the customer indicated that they didn’t want to see the routine “who we are” corporate slides, nor did they want a lot of time spent on references. What was important to them was the demo. While I was happy to ditch the standard corporate slides, I decided it was important to include a customer reference in my opening. So I had one reference slide which I spoke to briefly. For the rest of the demo, the name-dropping approach allowed me to regularly reference other customers in a short and simple way.

Started with a teaser of what they would see in the whole preso

Slide 2 of my presentation was a relevant, colourful screen shot. It filled the screen, as if we were looking at the application, not a slide. I briefly explained what they were seeing, and why it was useful, promising that I would come back to it again in the demo, after presenting some introductory slides.

I want to give a callout to Peter Cohan and Great Demo! as I had read Peter’s book and attended one of his workshops not long before this demo took place. Peter talks about starting with a Situation Slide and an Illustration. While I did not use a Situation Slide here (change comes slowly!), the value of the Illustration was to quickly grab the audience’s attention. They were here for a demo, so I wanted to show them a glimpse of the product straight away. It got them interested and paying attention, which contributed to building engagement throughout the session.

An analogy here is the beginning of some TV shows and movies, where they immediately start with a scene that introduces action and sets up the story, before then rolling the opening credits. The explanation and detail behind the scene comes later, but our attention has been caught early.

Gave an agenda which was about the benefits they would see in each part of the preso
Checked that everyone was on-board … and did it in such a way that they actually meaningfully engaged with feedback

We had responed to a tender document and the customer had specified what they wanted to see in the demo presentation. I used their own words to summarise their requirements and linked that to a proposed agenda, based around four functional areas. Importantly, I paused here to ask if this agenda would meet their expectations and if the planned order was correct. This led to a brief discussion by the customer participants about what was most important to see, and a validation of my plan.

I had prepared well, and did not have to change my planned approach. What I gained was insight into the priorities of different individuals, and a sense of where to spend more or less time. I also got them talking early, which broke the ice and led to positive questions and interaction as we progressed.

Constantly talked about ways they could get business value from functionality

A common complaint I hear about Presales is that we talk about features and functions, not value. We focus too much on the what it does or how it does it and not enough on the why this helps me or the so what? A good question to keep asking yourself when preparing a demo is “how (and who) does this help?” or “why is this useful?”. And broadly, to have a business value perspective, the answer should link back to increasing revenue, reducing cost or mitigating risk.

Talking about value is something I have practiced and trained myself to do over time. The rough “formula” I use in a demo is along the lines of, “Here we can see [a capability, or information]. This is important because it helps you to [a business benefit or value]”. And sometimes the follow on is, “As an example, [Customer ABC] was able to reduce their costs by x%”

Question answering is masterful. Makes it sound like a great question. And answers it from a business perspective (with a tool demo backing that up)

One good technique with questions is to always compliment the asker: “that’s a great question!” or “that’s a good question”. As Peter Cohan says, there are never bad questions.

When asked a question, one thing I want to consider is the reason behind the question. What is the value they are looking for? Or what is the thing they are confused or uncertain about. It can also be good to ask a clarifying question back, to make sure you have understood and to potentially uncover more information. When answering, I also try to always include the why this helps, just as I do when demonstrating a capability.

A new approach I used in this presentation was to have a Word document open in the background. If the question asked was something I didn’t want to answer immediately, I wrote it down in the document. It was the virtual equivalent to a “parking lot” whiteboard or flipchart – the question was visibility captured and permission was granted to come back to it later. It also served as a useful visual tool for doing a recap and summary at the end of the demo.

Another factor in this situation was that I know the subject matter deeply. It helps that I have years of experience in using and presenting the solution. This is harder to train in people, but my advice for Presales is that you need to know your products extremely well. Take time to install, configure and modify the software. Practice your demos over and over, and get across new features and capabilities as they come out. It’s also important to visit existing customers and see how they are using the software, and to learn what challenges they are having. If you can help them solve an issue, you have made that customer happy, and have learnt something that can help you when a related question comes up.

The outcome was the best customer engagement that I have seen for a long time…

This was a great example of a demo going well (sadly, not all my demos have been so good and some have failed badly). Apart from the positive feedback from the sales rep, another proof point was that the customer attendees asked lots of questions throughout. It slowed me down, but the customer attendees were so engaged and interested they agreed to stay on the call for an additional 30 minutes!

I hope that I’ve been able to reflect on and share some techniques and tips that may prove useful to you. The core takeway for me is the importance of relating capabilities to business value. Linking seamlessly and repeatedly from what to so what?, while dropping customer names along the way.

How does what you are demonstrating deliver value to the customer’s business?

Thinking about… My most difficult demo

Takeaway: Look out for your colleagues and step in when they need support

“What happens if you click that link in the corner?”

I was asked this question during a demo, by a hostile audience member. This person (who I later learnt was a supporter of our competitor), was not impressed that I was showcasing our software using only a static, click-though demo. She seemed determined to make us look bad and kept heckling me, to the point where I lost my temper when she challenged me again about not using a live demo.

This difficult and painful demo experience occured early in my Presales career. I was asked to showcase our project and portfolio management software to an audience at a large Telco. I was confident with the software and the subject matter and at the time had two demo options available to me: a live demo environment running as a virtual machine (VM) image on my laptop, or a canned click-through demo that we called a Fast Tour (Essentially a html mockup of the application using real screen shots, but with static data and a limited set of navigation paths).

The Fast Tour was very useful for initial customer and prospect meetings, as it was quick to launch and easy to talk to. I would always explain that it was a static demo, and would position a live, tailored demo as the appropriate next step, if the customer wanted to explore our solution further. Getting the live demo started and running smoothly could easily take 10 minutes, due to the need to start up the image, launch the application, then login to pre-cache the web pages and avoid slow wait times during the actual demo. So I tended to prefer using the Fast Tour when I could.

Prior to this demo at the Telco, I talked with the Sales Rep for the account and also a Sales Specialist who was involved, to understand the goals and expectations of the meeting. It sounded like an initial introductory or educational type session to a small group of people, and they advised that the Fast Tour would be sufficient. I distinctly asked my colleagues whether the Fast Tour would really be appropriate, and they gave me a confident “Yes”. You can guess where this is going.

What made this a difficult demo wasn’t just the heckler in the audience. First, the audience was much larger than I had expected (about 20 people) and they had come expecting to see our product in action, not just get an introductory overview. I was caught out by a misalignment in expectations. This was the classic scenario that demo trainers warn us about. I had not spoken directly to any customer stakeholders and had relied instead on the sales team. (The Sales Reps were experienced, so I suspect they were also caught off guard by the larger audience.)

So even if I had followed best practice and met with the customer beforehand, it may not have avoided this situation. These days, I do my best to speak to the customer several days before a demo, or to at least get more information from sales about who will be attending. The other thing I have got better at doing is using the opening 5 minutes of a meeting to understand who is in the room, and what they want to get out of the session. I can then tailor my message and demonstration appropriately, as well as managing their expectations before I launch into the presentation.

For many years after this experience, I only delivered live demos. I had been badly burnt and felt more confident having the flexibility of a live environment at my disposal, even though the setup was more painful. There was also risk: one time I was all ready to go and accidentally powered-down my laptop by pressing the power button with my arm, requiring another 10 minutes to get it back up and running! These days, I don’t do many demos, but when I do I use an always-on SaaS environment, which makes it very easy to get started.

The second thing that made this a painful experience was that when I started getting harassed and became flustered, neither of my sales colleagues backed me up. They both remained silent, leaving me to handle the situation on my own. Maybe they had full confidence in me, but this was actually the thing that made me most upset after the demo was finished. What I wanted was for them to speak up, support me and smooth the waters. Especially as I blamed them held them responsible for directing me to use only the Fast Tour, and not a live demo, and they were the ones who had previously met with the customer. Even remembering and writing this now, I’m feeling annoyed. When I angrily challenged the heckler back with “Yes, I can get a live demo running right now if I have to!”, I feel like it should have been obvious to them that I needed help.

I’m not completly sure what the advice for avoiding this sort of situation is here. Maybe it’s something that can get covered in rules-of-engagment discussions between Sales and Presales. One suggestion is for Presales and Sales to have some agreed signals: for example, moving a bottle of water on the table, asking if your colleague would like a glass of water, or having an agreed code word for “help!”. This sort of thing is easier to develop if you are regularly working with the same Sales Rep, so may not be practical.

A tangible action we can take is to be the one to step in and assist when a colleague is struggling or being pressured. Making a few comments or re-directing the conversation can give your teammate time to pause and gather themselves, before continuing on. It’s not always easy to judge the timing, and I’m the first to say that having sales people interrupt me is annoying, but we work best when we work together as a team, and that means looking out for each other.

What has been your most diffucult demo? What did you learn?

Thinking about… Writing a blog

Takeaway: Start somewhere and keep an eye on the future.

I’ve been thinking about this for a while.

The name of my blog might be a clue – I like to think things through. In the various personality- strengths- or profile-tests I’ve done over the years, I invariably show up as strongly analytical, requiring time to think. And it’s not an unusual trait for those of us in Presales. We like to understand the detail, get our facts straight and take time to prepare.

There are a few reasons why I’ve started this blog. The main one is that in the future, I’d like to be a consultant / facilitator / trainer / coach, working with Presales and Sales people. I have a lot of experience in this space, with many years as a Presales consultant, managing Presales teams, and working with Sales and Presales professionals to sell enterprise software. I’ve also had great times planning and delivering workshops, conferences and training and think it is something I am good at. While I currently have a secure role with a good company, things can change quickly in our business. I’m also getting to a stage of life where the idea of semi-retiring and working for myself is quite an attractive idea.

In thinking about a possible future career as a freelancer, I realised that producing content is a good way to build credibility. Experts I have engaged to run training for my teams have done research, written books or created videos. They have something tangible to point to that reflects their experience, thinking and knowledge. So, I’ve decided to create this blog and set a goal for 2021: post 25 articles in one year. Basically 1 every 2 weeks. As goals go, it’s Specific, Measurable, Achievable, Realistic and Timebound (those good old SMART goals) and it also ticks my box of setting only a few goals or KPIs.

I’m not going to set any up-front constraints on topics, style, length (or even quality). I’ll see how things develop and hopefully refine my voice and style over the year. Broadly, the things I plan to blog about will be about or related to the life and role of a Enteprise Software Presales professional, also known as a Sales Engineer (SE), Technical Sales, Technical Consultant, Solution Consultant, Solution Architect, Value Consultant, etc.

The purpose of doing this as a public blog is to encourage me to keep at it, to have a clear audience in mind, and to provide a tangible set of deliverables at the end. Maybe in the future I can turn these into a book, training materials, or use as the basis of a podcast. Who knows? I’ve decided to do it anonymously for now, partly because I have a day job, partly because it’s about the content, not me, and partly because it makes me feel more confident.

To finish up, let me briefly introduce myself. These days, I usually describe my role as a Business Consultant or Value Consultant (or Business Value Consultant) as I focus more on value, strategy and cross-portfolio solutions. I started my presales career in 2004 as a solution consultant, specialising in a single product (I still get called on periodically to demo it). Then I moved into Presales Management and have also worked in regional APJ (Asia Pacific Japan) sales organisation roles including Strategy and Sales Excellence. Prior to joining a software vendor, I worked for a major consulting firm for 11 years, where I learnt a lot about software development, testing, project management, application support and team management.

If you’ve read this far, thank you. I hope my journey and experience sharing can help you in your own Presales role and career. While I’m posting my blogs anonymously as “Thoughtful Presales”, I’m not completely hiding my identity. My name is Matthew Bertram, based in Melbourne, Australia. I’d love to get a connection and hello via Linked In.

Maybe you are thinking about your own career path. With an eye on my future, I’m setting a goal of content creation as an action I can take. Whether it helps me with my next career step or not, I’m excited to have a goal and a project to work on.

I’ve been thinking about writing this blog for about 2 months now. Time to get started.

What career goals are you thinking about and what action can you take right now?