Max Landis' bona fides include just a few past screenwriting credits, then the cult movie Chronicle and the YouTube video The Death and Return of Superman. Apparently he has something like twelve scripts sold and in production. In an unconventional profession, Landis is a bit unconventional-er... (more unconventional) than many. He cleanly acknowledges this and spends solid parts of the podcast describing what goes in his mind as he as creating. Midway through the podcast, he starts weaving a story idea of a British sailor in the late 18th century. The technique he uses to 'pitch' this story he will then reveal is his favorite of three approaches of pitching a script to movie producers.
The first approach Landis describes is to pitch the script by talking through the plot scene-by-scene. The second approach, he uses in the British sailor story, is to talk about the script as if you just saw the film and want to talk your friends into seeing it with you. The third approach he mentions is to start with an idea, a potentially big and abstract idea, and flesh it out with possible scenarios that would center of the idea. Now can we pitch, or sell, or present, a software solution using these approaches?
Scene-by-Scene
The scene-by-scene approach is traditionally used in pitching software solutions. It is what I learned at University in courses on Software Development Life Cycle (SDLC). In this approach, you gather the requirements and present them back as data flows or process charts. Waterfall models, stereo-typically, exude this step-by-step sequential feel. Also, agile techniques such as Use Cases and User Stories can have a fairly rote sequentiality. The process starts at point A, goes through these steps and ends when point B is reached. Some demos and slide decks follow this approach: this is how you log in, this is how you search, this is how you view, this is how you edit.
This can work. Just like the example in the podcast of a script for a movie where the studio already has the idea. It is a sequel, or a remake, or just the idea has been developed independently. This can be a situation where the solution is routine or the customer already knows what they want - but doesn't know if you can do it.
I've presented quite a few solutions with this style, and most were to an extent already initiated or just matter-of-fact accepted. They may have been required regulatory compliance and my solution was pretty much the only alternative available and feasible.
On the other hand I have pitched at least two projects using this approach unsuccessfully. At least one I wish had been successful. In that case, there was a opportunity to provide some automation support for California prison staff that traveled around that state negotiating transfer of prisoners between prisons. They had to take into take into account a number of factors of each prisoner's criminal history, manually cross reference availability at other locations and then print appropriate documents to authorize transfers. I led a team that both did site visits to see this process firsthand and had subject-matter experts visit and review documentation. I presented it back to leadership as mostly flowcharts and diagrams, to sort of... prove that we understood the need and were technically competent. But none of the documentation really resonated and the project didn't go anywhere at the time. This customer may or may not have been willing to do the work if I had presented it more vibrantly.
Another project, I will confess, I was glad was not selected. It was for a subset of results from a specialized type of audit. I had taken the approach of presenting a brief but thorough scope document that mostly focused on the structure that would be needed to provide reliable, trust-able numbers while most of the stakeholders focused on the high-level summary output output. This was largely to tease out the customer's willingness to commit their resources to doing detailed quality work such that the reporting would be reliable and sustainable over time. They weren't... and so the 'scene-by-scene' technique was effective in bearing that out.
Talk about the Solution as if you have Seen it
This technique can definitely be used to pitch a software solution, and it is definitely more difficult. Classic techniques such as storyboards and prototypes are probably the most obvious tools used in this approach. It's not just the use of them, though, I've found. The sequence and pacing and story being told through the purely visual artifacts is important. In this technique, it helps to talk present tense tense - you're talking about the business process as it exists with your solution in place. The client wants to get to this place and should start talking in the same present tense: "Yes, and we have ..," or "Exactly, then we do ..."
Landis in his script-pitching process will describe the script in a 'loose' way when pitching, leaving a lot of details to the imagination, not necessarily telling the audience the entire ending in one sitting. When using this approach to pitch a software solution I tend to skip over things like logging in or key entry and menu navigation. Not because they're not needed, but because they don't directly help the end state be visualized. They exist 'around' the goal. To the extent possible, I would even argue as a philosophy to minimize the these tertiary features in the eventual solution. With the movement towards 'apps' vs. applications, 'chromeless' windows, single sign-on (SSO), this seems to be a trend throughout the software industry.
The 'pitch' of the software solution need not be complete and comprehensive. If the customer intrigued by the start of solution, showing them only one logical path to an end point ends the creative process. My interpretation of this to leave out a lot of features. I try to be careful not to imply we missed them or don't know how to deliver a feature, but instead make it clear that there is a lot of, perhaps infinite, unexplored ground. For example, a grid view in a application might have a related print-friendly report. Then when you show the next grid view, the customer expect to see a print-friendly report, or email link button. Given the ability of modern development environments and platforms for reuse and patterns, filling in the 'story' to meet the customer's expectation could require modest effort.
The project that comes to mind that I have 'pitched' this way was a need to bring data from electronic-filed court documents into a custom application. This started with a call from a client, I vividly remember, on a day I was home sick. I made a special effort to take his call because I knew he was concerned about our ability to service his needs on some new types of court cases he would be involved in very quickly. I described to him what he would see on the court's website, then where it would show up in his application. All the while I was being honest and realistic about what could be done. I even described to him data that might not be exist in the electronic-filed documents or fields that might be unreliable, where he would have to manually edit and fix entries. The next opportunity to 'pitch' this was with a prototype using a pilot court case. My prototype made a point of showing the court's website in one window and showing the custom application's data in a second window. The visibility wasn't a technical requirement, but showed the process
If I recall, the prototype was more functional then it needed to be. The pilot court case was known well in advance and many features could have been hard-coded. We had already started down the road of using a bevy of patterns and practices that would eventually be required. Since multiple courts had their own formats, interfaces were used, files were imported from the web and translated to XML, then deposited back into a data layer. But it was the narrative told through the prototype, not the detailed flowcharts that helped the client visualize his business operating with my software solution in place and gave him the confidence in our ability to support him.
The Abstract Idea
The third approach was just starting with an idea, a sort of central theory around which a need or opportunity existed. Starting with the abstract idea is really hit-or-miss. I think inherently you have to take a lot of swings and expect just a few that gain any traction. How many back-of-the-napkin ideas have you discussed with a client or customer? How many of those gained any traction? Of those, how many ended up being funded projects?
My experience is getting many of these out there, many of them nothing comes about. In other cases, I may not be the one selected to pursue it. A good attitude to take when you are involved in this idea generation, if the customer or client pursues it some other way is just to think 'great for them, they'll probably come to me when they want to do X project or have Y need'.
One idea that I pitched and pursued was for an organization that had a ton of headaches around employees transferring between work assignments. One of the headaches was that the employee's user names contained an acronym indicating the location at which they worked. To keep this manageable, the user names had to be changed upon transfer. This disrupted the employee This disrupted any other systems to which they needed access rights. (SSO was some ways off) I was the supervisor of a technical support unit for one of the location so I had some ability to influence. The idea was, 'what if the employee's account name was just their first and last name?' With my team we filled in gaps around the idea: let's do this if two employees have the same name; let's handle employees with special accounts this way. Since we controlled at least the user names of new employees to our location, we put it in place with local management support and it later became a standard for the entire organization. Now, this isn't that 'big' of an idea and undoubtedly I wasn't the first one or only one to have it, but it should show how just starting your 'pitch' around an abstract idea can actually be put in motion.
Is pitching a movie script like pitching a software solution?
(Note: in the Nerdist podcast, the specific discussion about the pitch techniques starts at about 1:26:00. The British sailor story pitch starts around 45:00)
