Software is perceived as an intangible product. You can’t pick it up, weight it, or even see it. Building software is not like building an Ikea swivel chair which is, in fact, very tangible and knowns are, well… known. That isn’t the case with software. With software, everything is not known from the outset. There is no set of directions and all the pieces are not included. And more often than not in software, requirements change as things get built and new learnings are discovered. Yet since software is perceived as intangible, product features are expected to change at the same rate.
This is where the greatest complexity in software product development gets introduced.
Let’s go back to our Ikea swivel chair. If you pulled all the pieces out of the box and began to assemble but soon into the process realized that the chair you need must recline too, a trip back to the store would be in order. Identifying that the chair needs to recline (and understanding all of the implications of making the partially assembled chair recline when its original intent was to only swivel) is exactly where a sherpa can serve as a guide, making sure that the required chair ultimately gets built within an acceptable schedule and budget.
So what is a sherpa and what does it have to do with an Ikea chair? Well let’s first sub software in place of the Ikea chair. In the context of software product development, a sherpa is someone who understands the software product development process. They have spent years in the trenches building and delivering products from conceptual sketches to prototypes to fully deployed enterprise-grade solutions. They have battle scars from schedule slips, blown budgets and scope creep. But more importantly, they’ve figured out how to mitigate those snags. They know how to fix them and avoid them in the future altogether through open, frequent communication. A sherpa knows what’s coming at every stage of a product’s lifecycle and guides both his or her team and the customer through to success.
A sherpa operates on process—discovery, design, development and deployment—to take “hacking code” to a higher level into building meaningful products. And that’s what differentiates; that’s the difference between a customer getting a piece of software that’s basically off-the-shelf (the Ikea swivel chair that can’t recline) and getting a product that truly solves a specific problem and has a direct impact on their bottom line.
Why Value a Sherpa?
Customers are often focused on the business value of the software product and rightfully so. However, even experienced product people who understand development processes often find it challenging to execute a complex software product development project in parallel with juggling critical business tasks such as sales and marketing, finance, integration with existing tools or processes, etc. But the bottom line remains: total project success is predicated on embracing that product-business duality. A sherpa is a partner that can take ownership of the technology and ensure its delivery through the complex development process while also identifying and advising the customer of the technological impact on business value. It is in that partnership that the right software product is built for the right business objective.
Why Sherpas Instead of Software
If we knew everything about building a given software product from the outset, we could simply develop a set of requirements, crank out the code, test and deliver. End of story. But we don’t know everything. If we simply built a product based on what we knew at the beginning we’d more often than not end up with an inferior product. (Think about the Ikea swivel chair that needed to recline too.) It’s usually that one unknown realized in the middle of development that distinguishes a mediocre product from a great one.
A sherpa helps a customer effectively navigate the critical decisions that must be made throughout the product development lifecycle in order to realize the right solution to the right problem. They understand and can manage the product-business duality. They anticipate and, more often than not, know what hurdles are imminent—and they know how to mitigate them. Said differently, a sherpa doesn’t just hear your ask and simply hand you a piece of software. A sherpa is your experienced guide, every step of the way.
Building a digital product?
Want more insights like this in your inbox every now and then? Sign up using the field in the footer.
