Mission-Critical Service Testing Fundamental #6: “Test Your Services Under Anticipated Load” Webinar is now available

March 23, 2014 § 1 Comment

Load testing is an essential, but often overlooked aspect of making sure your services are ready for prime time. If this topic interests you, be sure to check out the next installment of my ongoing series on service testing best practices. You’ll find the newest Webinar here.

If you’re interested in being notified of future editions, subscribe to the blog or follow me on Twitter: @RD_Schneider.

I’m hosting a prospective member virtual event for Astia Angels on March 24

March 9, 2014 § Leave a comment

How often do you get the chance to do the right thing, make great connections, and profit from the experience – all at the same time?

Astia Angels, launched in early 2013, is an international network of male and female accredited investors that puts capital to work in women-led, high-growth ventures. All Astia Angels members are highly involved throughout the investment process and make independent investment decisions. Astia Angels holds regular in-person pitch meetings in Silicon Valley, New York City, Boston and in London in 2015. Astia Angels also participate on virtual presentations and national phone calls. Astia Angels is a program of Astia.

Members of Astia Angels:

  • Get early exposure to community-screened, high potential companies
  • Participate in an organized process that ensures the wise and effective use of their time
  • Profit from Astia’s proven, proprietary process that produces high-quality deal flow
  • Engage in post-investment programs that contribute to the success of the portfolio companies
  • Network with the Global Astia Community, including invitation-only events and programs
  • Join a growing movement to increase the funding for women-led, high-growth companies

Want to learn more? Sign up for the Astia Angels virtual meeting that we’re holding on March 24 at 4 pm PT, 7 pm ET.

Proof of concept best practice #3: The POC must have a clearly defined set of goals

February 3, 2014 § 1 Comment

In earlier posts in this series, I’ve talked about why proofs-of- concept (POC) are so essential when attempting to get customers to buy a complex product or service, how they must already occur as part of an active sale, and that they must have a sponsor at the prospect – on both the business and technical sides.

Now, it’s time to discuss how to increase the chances of your POCs succeeding by setting well-understood, widely communicated goals up front. After all, the sale isn’t going to happen without a POC, and the POC itself is much more likely to ignominiously fail if you neglect to gain agreement on exactly what concepts you’re supposed to be proving!

Don’t lose sight of the fact that the burden of proof for a POC falls squarely on the company trying to make the sale, and that the sales engineer (SE) is usually personally responsible for ensuring a positive outcome. Despite this reality, I’ve seen astonishing numbers of POCs that proceed without a single written sentence that describes what’s supposed to happen. Given that lack of guidance and accountability, is it any wonder that so many of those impromptu engagements end in tears? It’s much wiser to write a proper, comprehensive statement of work (SOW) for the POC – just like you would for a professional services engagement.

At a minimum, the SOW should unmistakably document the POC’s:

  • Goals. Be specific, and cite easily understood concepts like use cases, data or transaction volumes, and availability/service level agreements. Checklists are great for this.
  • Schedule. Time is of the essence in a POC: unlike consultants who eagerly seek ways to boost billable hours, the most talented SEs must be efficiency experts.
  • Responsibilities. A POC is usually a team effort; make sure that everyone’s role is plainly spelled out.
  • Next steps. Since you’re not doing this POC just for fun, there’s no harm in stating that a purchase of your product or service will take place upon successful completion of the POC. And if the client won’t sign off on a SOW that references the expected sale, guess what that means?

I’ve worked with quite a few technology companies to help optimize their technical sales processes. If you’d like to learn more, you can email me here.

Mission-Critical Service Testing Fundamental #5: “Fully Track Your Test Results” Webinar is now available

January 26, 2014 § 1 Comment

The fifth episode of my ongoing seven part series on service testing best practices is now available on the SmartBear blog. In this installment, I talk about why it’s so critical that you keep a record of your test results. The Webinar is available here.

If you’re interested in being notified of future editions, subscribe to the blog or follow me on Twitter: @RD_Schneider.

Free e-book on Web API design

December 15, 2013 § Leave a comment

Let’s face it: designing a good API – whether using SOAP, REST, or anything else – is equal parts art and science. I’ve enjoyed reading Brian Mulloy’s Web API Design e-book, and I wanted to share it with my readers. I particularly liked how he references API implementations from various players like Google, Foursquare, Digg, LinkedIn, and so on. It’s interesting to compare the variety of designs that these vendors have chosen.

You’ll find the e-book here.

Screen shot 2013-12-15 at 9.32.18 PM

Hadoop Buyers Guide is now available

November 25, 2013 § Leave a comment

Choosing a Hadoop platform can be confusing: there are several great alternatives on the market right now. Some of these offerings require you to handle all aspects of installation, configuration, and administration on your own, while others deliver a more comprehensive, innovative, and integrated solution yet are still faithful to Hadoop’s open source heritage.

I recently put together a concise eBook that you can use to help get a better understanding of your options.  You can view the guide here.

Proof of concept best practice #2: The POC must have a client-side business and technical sponsor

November 12, 2013 § 1 Comment

In the introductory post for this series, I present a list of POC suggestions that I’ve learned – too often the hard way. Next up, I describe why it’s so important to have client-side sponsorship.

I’ve already written about why a POC should only happen when there’s an active sales opportunity. Assuming that there’s indeed a live deal, there are still many ways for things to go off the rails. First, every substantial technology sale I’ve ever been involved in was impacted by client-side politics. After all, any significant new systems, processes, or technologies will affect large numbers of people. Some will be strengthened by the purchase, and others will be weakened. These machinations are often invisible to the sales team, but trust me: there are definite winners and losers, your client’s employees know this, and this impacts how every one of them will behave regarding your POC.

This means that there’s a very good chance that some individuals will be rooting for your POC to fail. Resistance may be passive, such as taking a leisurely three days to respond to your emails and calls, or giving you wrong or incomplete information. You might also encounter active opposition, even to the point of deliberate sabotage of your POC.

Given that every POC is a potential minefield, you need at least two trusted guides to help you get through safely. These sponsors should represent both the technical and business side of your prospect. It’s a huge red flag if your client won’t assign anyone, or if they assign people who don’t seem to have the respect of their colleagues.

Good advocates will help remove barriers to your success. They know the landscape far better than you do, and they can head off the active damage to your POC – often without you even knowing that they were acting as your guardian angel. In particular, a technical benefactor will quickly get you access to the resources you need – which is helpful, since time is of the essence on a POC. And a business champion will be intimately involved in drafting up the rules and goals of the POC.

As a sales engineer, you need to speak up – to your sales rep – if you determine that your sponsors are weak, disinterested, or not giving you the resources you need, because guess who will get blamed if the POC fails?

If you’re interested in POCs and all things related to sales engineering, check out my posts on the habits of the most effective sales engineers.

Follow

Get every new post delivered to your Inbox.

Join 60 other followers