Turning Technical Mountains into Molehills

By Leslie Osborne, Head of Product, VineSpring

At VineSpring we believe in the benefit of connecting best-in-breed systems to surround your winery with a powerful, future-proof ecosystem of tools that help you achieve your ongoing business goals. For our winery clients, undertaking the associated technical projects can sometimes feel like staring at the top of Everest…from the base of Everest.

I’ve been working with software engineering teams to build web and mobile applications for 20 years. When it comes to figuring out how to create a new software feature or integrate with a new system, how to approach those projects is like second nature to me. Let me help you skip the 20 years of prep. Here are five tips to help you successfully undertake your winery’s next technical project and turn that mountain into a molehill.

#1: Understand clearly what problem you need to solve

Often when beginning a technology project we come to the table with a predefined solution. “We’re going to do X!”. While that works fine in some cases, in others it can close us off from other, potentially better solutions to the problem we actually need to solve…or, worst case, our pre-defined solution may not solve the true problem at all. That’s why at the start of a technology project, it’s important to be clear about what problem we need to solve and why we need to solve it. We might say, “We want to build a new custom storefront to better present our allocations to customers.” Sounds pretty straightforward, right? We hire a developer and off we go.

But why are we building this new storefront? Why do our allocations need to be better presented? What problem (or problems) does this new website actually need to solve…and do we even need a new website to solve them? Let’s rewind and say we do some thoughtful review prior to undertaking this project. We’re relatively new to allocations, so our offering is quite simple. Our membership is small but growing and we want to be better at presenting the right allocation offerings to our customers, preferably in a more personalized way. We want to accomplish all of this with the same staff we have today. We also want to do our best to maximize sales, of course. So just saying that we need to “better present our allocations” is a solution but doesn’t really address the problem we’re truly trying to solve. The problem we actually need to solve is: How to maximize our allocation sales across a larger audience, using the same staff we have today, in a way that feels personalized to the customer.

Now that we have our problem, let’s go solve it.

#2: Consider phasing your solution

One of the temptations with any project is to do all of the things — solve every aspect of the problem, 100% of the way — all at once. You do that and surely the problem is perfectly solved, never to be thought of ever again, right? Maybe. …but it’s also kind of daunting to take on a project like that, often takes a lot of time, you wait until you get this magic solution at the very end of the process, and you hope it works perfectly. Boy, that’s a lot of pressure and risk!

To help mitigate risk and provide tangible value all along the way through a project (instead of getting the value in a big bang, at some point in the future), we typically break technical projects into phases. So as a reminder, our problem to solve is: How to maximize our allocation sales across a larger audience, using the same staff we have today, in a way that feels personalized to the customer. Our solution phases could be:

1. Create optimized allocation tiers (in an automated fashion, ideally).
2. Update our storefront to accommodate these more optimized offerings (if needed).
3. Add personalized allocation welcome messages to the storefront for customers in each tier.

Each of the above phases has an independent deliverable, so we can realize value from each deliverable without depending on the others to be complete. That helps us feel the progress of a project, which can help maintain excitement. We’ll also tackle the phases as listed in the order above, starting with the most complicated piece. By starting there we mitigate as much risk as possible, as early as possible, in the project.

#3: During development, be engaged

You’ve found a software developer with whom you want to work on these solutions. It’s entirely possible that you already brought your problem to them and collaborated together on the solutions and how to phase them. (If so, yay you! Software developers are your friends!) So what do you do now?

You wouldn’t go ‘off the grid’ while your dream home was being built, would you? Same goes for a technical project. Staying engaged all along the way is key to the quality of the outcome. The first step is to do some planning. You may need to figure out if there are other software tools or software vendors with which you’ll need to integrate. You’ll likely otherwise need to create screen designs and plan out the flow of your solutions. It’s possible your software developer will do some or all of these activities for you, but you can (and should!) be engaged in this work as well. And don’t think any of this work has to be formal to be useful — some of my best and clearest user flow diagrams and system integration diagrams were hand-drawn on a piece of paper. Keeping it simple is perfectly ok.

To discuss the next step in detail, let’s use the first solution phase, “Create optimized allocation tiers (in an automated fashion, ideally).” For this phase we have some homework: We need to make a “build or buy” decision: Do we want to build a custom tool to craft our optimized allocation tiers or use an existing software tool for this? To answer this we first make sure we’re clear on what we need from a tool. Then we research what’s currently available on the market, get demos, and take them for a test drive. We also discuss with our developer what options he or she could custom-build for us. At the end, we decide a custom tool best meets our particular needs and budget.

We work with our developer to design the user interface for this tool, which they build and integrate to our eCommerce system’s APIs, such that the tool may automatically gather data for analysis and provide the output back to the eCommerce system when it’s time to create and open the allocation. We check in with him/her along the way, get to see the work in progress at appropriate milestones, provide feedback, ask and answer questions, make small tweaks, and are thrilled when we receive the end product. We enjoy getting to test it out, perfect our process for using the tool and perfect our allocation tiers, al while we await delivery of the other phases.

#4: Launch small

We’ve been progressing through the delivery of our solution phases, enjoying the benefits of each deliverable as they’ve become available, and now it’s time to bring them all together. Exciting! Let’s do our big allocation release!!! Go!!!!!! Hold up there, partner…

While it can be super exciting to have all of your shiny new tools ready to roll, it’s always a good idea to first launch small. Think of it as a soft opening at a restaurant. Even though the restaurant staff has been training for weeks and knows the menu inside and out, inevitably when the entire system comes together, including customers, something will come up. Just like phasing can help mitigate risk, so can a soft launch.

Launch just to the people on your team. Launch to a small group of friends and family. Were people prepared for the changes? What sort of feedback did we receive? Most importantly, did we solve our problem? If not, tweak, then test further.

#5: Launch big

Once all of the above has gone well, then launch big! Grab a glass of your wine and bask in the glory of how well you’ve just run this technical project and solved the problem at hand. Cheers!