From Features to Experience: What it means for a Software Product?
In a fast-evolving digital world, technology is at the helm of driving experiences. Simplistically, if you are a business then these can be experiences that you want your customers / consumers to have, when they interact with your brand, or, when looked inwards these can be experiences you want your own team and employees to have. The net is, in today’s interconnected world, while utility & benefits derived from a product is of course important, what really differentiates is the “experience” delivered by the brand.
What does this mean from a Software Product Development standpoint? In this blog, I want to focus on the need for a mindset shift while conceptualizing & developing a “software platform”. This change in thinking should place higher importance on platforms being able to enable experiences, and equip “on-the-ground” Product management & engineering teams with right tools to achieve this.
But first things first, let me define a couple of terms that I’ve quoted here to ensure we are speaking the same language. When I say, “software platform”, I mean an intertwined ecosystem of supporting software assets where each of them works together in an automated fashion, at scale. This ecosystem would aim to create what it takes to deliver end to end experiences. Moving on to second quoted term, “on-the-ground”, I’m alluding to the Product Management & Software Engineering teams building this platform. Think of UI / UX designers, Product management specialists, Software engineering and Program Management specialists here. To build this ecosystem of software assets, I am assuming the Platform Development team comprises of multiple separate teams working on their specific assets that’ll be later integrated (I’ll call them Asset teams in subsequent sections).
Enabling Experiences through Software Platform
While I’m on the subject of defining terms, one of the very popular terms that goes around with software product development is MVP. MVP stands for Minimum Viable Product and the focus here is on specific features & functionalities to be used / purchased by customer. Typically, Product Management will define this as a product having minimum viable features & functionalities that are needed to solve customer problems. However, what it does not focuses on is the overall experience that this MVP will provide to prospective customers.
This is where the concept of Minimum Viable Experience (this is a wonderful link to learn about MVE & also my reference to understand it better) or MVE comes to rescue. With an MVE, you are also looking to define how your software platform is going to help enable an end to end minimum viable “experience” while of course solving the primary problem at hand. When I’m talking about enablement of experience here, I don’t necessarily mean that these experiences are always created directly for end customers. Instead most of the times, the software platform may be helping business personas who are going to use & operate this platform in order to create a seamless & meaningful experience for their customers or consumers. In this context, it’s important that platform has most of the ingredients that business needs to cook their dishes. The switch to MVE results into a paradigm shift, where the need for all components working in unison to deliver experiences for chosen audience persona, cannot be overstated even if it means trimming feature set for sake of it.
Hence moving from an MVP to an MVE approach in a software platform context, necessitates a mindset shift, a change in thinking that needs to percolate to the level of junior most person in Product cross functional teams. And in my experience, one big theme that this eventually boils down to is: “busting the silos” at the level of engineers, designers, product, and program specialists. For a vision such as this, creating a holistic product means higher degree of complexity & integration needs, to be executed through efficiency in coordination. Of course, the vision comes from Product leadership and it has to be complemented by a well-defined program structure for execution. However, this needs to drill down to the on-the-ground team. There’s usually a need for a fine-balancing act so as to not overwhelm everyone with too much of information, but at same time make sure that the purpose and goals is well understood.
Busting the Silos
This is anyways essential in building anything that has multiple integration touchpoints. Add “Experience thinking” to it, and it becomes no brainer where the focus of leadership should lie. For me, to start off, it translates into three primary pillars:
- Think Strategic, Think Integrated!
Once the vision for “Experience” is stitched into Product Strategy, clear & succinct communication to all the Asset teams is important. Sharing bigger purpose can often inspire & motivate individuals. From an execution perspective, for each individual Asset tracks, it means while the tracks are focusing on the software asset they are building, they do not lose the sight of how their piece of software is going to bring in features & functionalities that would deliver experience on a whole.
When the team on the ground is thinking about integration and experience, it drives them to anticipate complexities that may come their way when designing touchpoints and handshake between different components of the system. There’s also a high chance of idea generation / innovation coming from all corners. For their individual assets, the on-the-ground team is constantly Defining, Designing, Detailing, & Developing (I call them 4Ds) features. This puts them in a unique position to bring in an executional perspective that can be very important in ensuring platform is delivering the intended experience.
2. Define Priority, Have Clarity!
When it comes to building and delivering a major release, for each Assets teams, it’s important that they set & understand priorities that will help achieve features & functionalities that are up for next release & how other teams may be dependent on them. This should typically be facilitated by the program team who would manage the roadmap & timeline for this integration project, so that individual Assets are able to gauge expectations for themselves.
Why is this important? In my experience, it’s not uncommon for Assets teams to have varying velocities for their backlog depending on nature of their engineering work. Hence, it’s important that each team has an appreciation of each other’s plans and they can use this understanding to prioritize dev items that are absolute necessities from an integrated platform standpoint. Often, I have seen teams going to achieve features that may be good for their own asset in silo with the cost of an important integration feature. And managing unprioritized, unclear plans essentially results into totally avoidable burnouts.
Another point to note is, priority setting is not a one-off activity at the start. Situations can change or rather Situations definitely change, and hence this has be to a continual endeavor. And to ensure this, Communication & Coordination is an absolute must, which also is my next pillar.
3. Communicate, Coordinate, Course Correct. Repeat!
Role of program management becomes important in defining process & frameworks that help in coordination between teams. The worst thing that can ever happen is, when an engineering team could have prioritized sprint work needed to unblock another team, but they never even knew! Hence pre-planning, calling out cross-team risks & dependencies a couple of sprints in advance and communicating them to teams are absolutely essential for far reaching productivity gains. A typical complex and multi-team program generally would use Scrum at Scale. Whether its Scrum of Scrums or any other way that works for you, the bottom-line is to be agile. This will also mean that if there’s need for course-correction, specifics can be highlighted and brought for discussion early enough to manage it better.
Information sharing is another important piece that I want to loosely couple with communication & coordination. A central knowledge hub with architecture and detailed design documents, lists of well-maintained github-repositories and other supporting artifacts can reduce coordination overheads to a high degree.
Most importantly the three Cs of Commination, Coordination & Course Correction, if not done sufficiently, in my experience it will invariably result into last minute putting off the fire which leaves engineers befuddled, anxious, demotivated & dissatisfied — not sustainable!
