So You Want To Develop Products

So you want to develop software products? Let’s start from scratch — the very beginning, a beautiful, untouched green field, ripe for planting the seeds of success.

The Product Development Team: Everything Flows from Here

First things first, you’re going to need Product Development Team.

Already, you’ve already made three very critical choices:

1. You are building a team.
2. Your team develops.
3. Your team develops products.

The Three Perspectives

As it turns out, these are also the three critical perspectives that must be maintained if you want to be an effective product development team: the Process or Project Perspective, the Technical Perspective, and the User Perspective. Maximizing the team’s understanding and application of all three perspectives directly leads to maximizing the team’s effectiveness — that is, the team’s ability to deliver working products into the hands of users in a timely manner.

Applying the Perspectives: The Primary Measure of Success

Did our primary measure of success just fall into our laps? Look closely:

The team’s ability to deliver working products into the hands of users in a timely manner.

What do we mean by working products? Naturally, it must be functional. And in fact, from the Technical Perspective, there are many techniques and tools available for us to maximize the quality of our product. Importantly, when we consider the context of into the hands of users, we understand that we have an obligation to meet the user’s needs by maintaining the User Perspective. (We could build the world’s finest screen door, but if our users are trying to operate a submarine, we have not delivered them a working product!) Finally, we stipulated that effectiveness is also a product of how quickly we can deliver our quality products to our users — an undoubtedly critical outcome driven by the discipline instilled from the Process Perspective. Bad process slows us down; good process enables us to move fast without sacrificing quality.

In other words:

• The User Perspective ensures we build the right thing.
• The Technical Perspective ensures we build the thing right.
• The Process Perspective ensures we deliver the thing quickly.

Applying the Perspectives: Team Composition

In an ideal utopia, the team would be comprised of highly skilled, highly disciplined members who communicate constantly and effectively and maintain all three perspectives with a steely focus.

In the real world, the natural consequences of a highly dynamic environment dictate a more pragmatic approach. There ought to be at least one person per perspective, whose job — whose role — is to keep the team aligned to that perspective. Thus, someone — the Technical Lead — should keep the team focused on the Technical Perspective, yet another someone — the Product Owner — should keep the team focused on the User Perspective, and a third someone — the Agilist — (or Scrum Master, or Project Manager, etc) — should keep the team focused on the Process Perspective. These roles have nothing to do with rank, but rather everything to do with the ability to become an authoritative voice on the team from a particular perspective.

Whoever is the Technical Lead should not ignore the the User and Process Perspectives, nor should they advocate to unbalance the project by favoring Technical value at the expense of Process or User value. Same goes for the other perspectives; the challenge comes in working in harmony. Anyone who has experienced a successful team can testify to the fact that harmony is only achievable through regular (read: daily) direct communication among team members.

A key factor to remember is to avoid a false choice where one perspective must always be selected to “win out” over the other two in every decision — rather, the team must remain committed to the concept that all three perspectives have equal value, and strive to maximize that value out of all three perspectives in every decision.

Expanding the Perspectives

As the team grows in size and maturity, specialized roles within the perspectives can emerge. The technical area can include DBAs, QAs, Automation Engineers, SDETs, SREs, and any number of other specialties alongside the Software Engineers.

Likewise, in the realm of User Perspective, there can be Designers, UX Specialists, Business Analysts, and others.

From within the Process Perspective, depending on the framework in place, there may be a Scrum Master, or a Project Manager, or simply an Engineering Manager; there might be the addition of an Agile Coach or Process Engineer; there might be the presence of an evangelist for a particular framework when none have yet been adopted by the team.

In their own way, each specialist strives to ensure that a particular perspective is maintained, and executed against in such a way that does not diminish the value of the other perspectives.

Team Artifacts

So you want to develop products? You have a team, and the team understands what they need to do — and all this came organically from simply wanting to develop products in the first place. But how to do it?

From here, the team must work out a flow — that is, the general steps it takes to take an idea at the start, and deliver it into the hands of users at the end.

Of course, the team will get nowhere until they agree upon the specifics of the start and the end. In other words, when is something ready to begin? When is something able to be declared done?

It is therefore paramount for the team to publish — and then hold each other accountable to — The Definition of Ready and the Definition of Done. Often, these are just a sentence or two — or perhaps a handful of bullet points. Regardless, having a solid, living definition for both Ready and Done means there is no confusion or debate when it comes to making those determinations.

Everything around and in-between falls under the purview of the Team Working Agreement. Here, the team codifies customs, norms, and any other specifics about their process. This can range from the seemingly mundane (eg, “We name our sprints after superheroes”) to the vitally important (eg, “the original assignee of a work item is the one responsible for driving that work item from Ready to Done,” and “All team members must be available for meetings between 9am and 3pm.”)

Getting Ready

An idea alone is not ready for work. There is a sub-process, however lean, of translating an idea into something the team can work on. In Agile, we call this process “Grooming.” Regardless of where the idea came from, the team must vet the idea and transform it (under the guidance of the Product Owner) into a user-centric story. Additionally, due diligence must be paid to the engineers (under the guidance of the Technical Lead) so that the developers have all the details and information necessary to actually execute against the story. Commonly, specific technical steps are added as subtasks under the story — these are not tracked in terms of performance metrics, nor would they matter from a Product Perspective, but they simply help spell out in no uncertain terms what the team feels is the best technical solution.

By the end of the Grooming, a user story meets the Definition of Ready, and the team is free to work on it according to its prioritization and dependencies.

Getting Done

As called out earlier in this piece, simply building something the right way is not sufficient for a product development team to be successful. We must also build the right something. There are many techniques and frameworks and philosophies and approaches to the nuts-and-bolts development of software products, but they all end at the same question: How does a team know when the work they have executed is complete? The general term for ensuring that a user story is done is called “Review,” and can take as many forms as the development phase itself. The bottom line, however, is that Review is the process by which a team ensures a work item meets the Definition of Done.

The Journey is the Worthier Part

Through it all, the flow is managed and executed under the guidance of the Agilist maintaining the Process Perspective. They are careful to ensure the team operates in sprints, so that they may regularly pause for introspection and adjustment. They help remove blocks, they seek to identify and eliminate bottlenecks, they manage expectations with respect to timetables, etc.

All this occurs as the team communicates regularly, balancing and maximizing their perspectives, and committed to a mindset in which they are always improving.

There is so much information to drill into and cover in detail, and so many branching topics to discuss and compare and contrast. But the foundational fundamentals of product development, as described here, should come naturally with just a little thought. Most of the decisions are made for us!

So… you want to develop products?

You can.