Product Management at a Software Development Shop

I lead product management and solution architecture at a software development company here in Austin, Texas. When I started a few years ago, product management as a practice did not exist at this company…and there were problems that the founder anticipated product could solve for our clients.

Fast forward a few years, and I’ve been considering: How is Product Management at a dev shop different than at a company that develops its own software products?

Cross-Domain Expertise

At most companies, Product Management tends to focus within the bounds of the company’s vertical, such as education or healthcare. At our dev shop, we partner with companies from a gamut of verticals to design and develop their products. Given our clients know their respective verticals and by extension their customers infinitely better that I, what value can I bring?

Working across so many domains, it turns out I have the unique perspective of seeing customer pains addressed over and over through products and their features. Over time, I’ve been able to distill out common successes (and failures) of the solutions, turning that experience into product guidance for every new client. Even knowledge of existing open-source and OTS (off the shelf) solutions used in one vertical prompts consideration for reuse or exploration within another vertical for possible solutions.

In short, I have become a consultant to our clients, lending those common solutions as we think through the desired features together, ensuring the task of reinventing a wheel isn’t undertaken, or at least without sufficient warning.

PM Maturity: Everyone is Different

Successful product managers must know their customers and business. In my case, every one of my clients should have at least one person who plays this role, even if not officially titled product manager. This is where things can get tricky, as not every client employs experienced or trained product managers.

As the product management counterpart for each client, I meet them where they are today, each at their own level of product management maturity. I’ve become well-versed in asking the right questions to distill out:

  • how well they understand the problems that need to be solved for their customer and business
  • the requirements that have been validated by their customers, and thus,
  • where they are making assumptions

Organizations with mature product management have this worked out, but others may need quite a bit of hand-holding through multiple conversations. It is in no one’s best interest to build the wrong features, or build the right features at the wrong time. As we figure out the roadmap, often my job is to think through and push back on proposed features to ensure the client is planning features that their customers want while fulfilling their business goals.

Solution Architecture

Quite a bit of my role overlaps into solution architecture, which is where my broad technology background and software dev experience tends to pay off. As I meet our clients during pre-sales and after the project commences, it’s helpful to know where the gotchas are fairly quickly, navigating the conversation to investigate further.

Example: the client wants to build a car, and desires the following features: wheels, windshield, steering, engine, radio, seats, and hover capability. It’s helpful to be able to state immediately that all but the last are fairly standard, but the final one requires orders of magnitude more time & resources. At this point, we can dive into that feature requirement and see if it’s truly necessary, or see if the root problem can be addressed in another less taxing way.

In addition, as the product management counterpart to our client, I have think through the features they will need for a successful release, including anticipating the back-office administrative roles and features which most clients rarely anticipate. Thinking ahead to how the client, given their own business processes + sales & marketing plans, will need to engage with the product post-deployment, cannot be underestimated. Surprised clients, in this scenario, is not a good thing.

Finally, as I alluded to earlier, when I interview clients to understand their business goals and customer problems, I naturally consider solutions I’ve already seen…whether partial-solutions as OTS software, or software products that exist in other domains. I often break down the customer problem and consider solution made up of OTS and custom components, all of which can be investigated by our design and development teams as a potential path for implementation. It’s a starting point for the internal conversations, and gets everyone thinking about development costs, cost of ownership, performance, integrations, and the like.

Client-Facing, by Nature

If there ever was a role that is client-facing, it’s product management at a dev shop. While traditional product management is encouraged to spend time with customers, there is hardly a day that goes by when I’m not speaking with a potential or current client.

Being genuine, friendly, professional, likable, transparent, and an excellent written and oral communicator are all required for this role. Most of our clients first engage with our dev shop via product management, and therefore we are the first impression. Then, collaborating with our internal UX design and software development teams before in pre-sales, as well as during the project, is imperative.

Suffice to say, in product management, it helps to be a people-person, and no less so at a dev shop.

Managing Process

Every software company must have some software development process to create products. Because dev shops are typically managing numerous projects across one or more clients, they live and die by process.

At our dev shop, we practice our own flavor of Agile Scrum. Clients hire us to develop software for them, and for many, this relieves them from building their own UX design and software development teams, and associated methodology. This also means many clients have no idea what “Agile” or “Scrum” is, and may themselves be accustomed to a traditional waterfall mindset of project execution. Training clients about the benefits and drawbacks of Agile is often required initially and throughout the project. This is a big difference between dev shops and traditional software companies, where the latter is presumed have all bought-in on a methodology.

In addition, the three pillars of a project (time, budget, scope) become quite literal when working with clients. If any or all of the three pillars were tied down contractually, product management must manage this with the client, and decide how to handle inevitable changes that occur during the project jeopardize success.

The traveling salesman, Steiner trees, and bubbles

Be forewarned: Of course no solution here, but rather a train of thought I want to jot down…if not for your consideration, then for me to pick up later. Also, this post mentions soap film, not bubbles. But who doesn’t like bubbles? Same generally can’t be said for soap film.

The Traveling Salesmen Problem is a hard problem. In fact, it’s NP-hard. Here’s a description (thanks, Wikipedia!):

The Traveling Salesman Problem describes a salesman who must travel between N cities. The order in which he does so is something he does not care about, as long as he visits each one during his trip, and finishes where he was at first. Each city is connected to other close by cities, or nodes, by airplanes, or by road or railway. Each of those links between the cities has one or more weights (or the cost) attached. The cost describes how “difficult” it is to traverse this edge on the graph, and may be given, for example, by the cost of an airplane ticket or train ticket, or perhaps by the length of the edge, or time required to complete the traversal. The salesman wants to keep both the travel costs, as well as the distance he travels as low as possible.

The salesmen needs to find a single loop to hit every city, and our objective is to find the least cost to make that loop. Let’s assume that cost is the distance: the salesman wants to get home as fast as possible.

OK, put that on ice for a moment and switch gears.

Another problem that also involves graphs is the Steiner Tree Problem, which is a little different. While you can still consider many cities as with the above problem, in this case we’re talking about road planning. How do you connect all the cities with the minimum distance of road pavement? In more general terms, what is the minimum length of edges that include all fixed points in the graph?

I was first introduced to Steiner Trees via this wonderful video by the good folks at Numberphile:

What astounded me is that we can “use nature” by exploiting an inherent property: get to the lowest energy state possible. Whether its water rolling down a hill to find bottom, or lightening finding the optimum path to reach ground, nature generally looks for the easiest path to get to the lowest possible energy state. In this particular scenario, the soap film expends as little energy as possible to maintain itself. The area of the film for a segment varies with the total length between the pegs. Nature wants to minimize its film area, so in doing so it also finds the minimum length solution for us. (The end of the video showed a local minimum, which by adding some energy, yielded the global minimum. Clever!)

The ultimate supercomputer

No calculations, no algorithms, no processing. Intrinsically, nature behaves like an infinitely-scaled parallel processor, evaluating all possible paths simultaneously in an attempt to find the lowest possible energy state that maintains itself. In my mind, this behavior is analogous to quantum computers where all states are evaluated simultaneously (for the purists, greatly simplified).

Via this exercise in the physical world, nature solved a mathematical problem by finding the shortest distance between a set of points. Can nature also similarly identify the shortest loop through a set of points for our friend, the traveling salesman?

Comparing the problems

The Traveling Salesman problem has the following properties (where I equate the edge cost to the distance between cities):

  1. Requirement to create a loop (in contrast to Steiner Trees, which have no such requirement), and therefore a traversal order is implied.
  2. Each city has precisely two edges connected to it (where Steiner Trees have at least one).
  3. All available paths and their associated distances between cities are fixed (whereas the paths between nodes in Steiner Trees are undefined from the start, and the paths with associated distances are solved for).
  4. The number of cities cannot be changed (whereas Steiner Trees can increase the number of nodes by adding Steiner Points if it reduces the total distance).

As I see it, the primary difference is that Steiner Trees solve for the minimum total distance to connect all nodes, versus the Traveling Salesman problem must solve for the minimum loop distance by identifying a traversal order.

Another way to contrast is that Steiner Trees are unordered because a traversal order isn’t part of the solution, and the Traveling Salesmen problem is ordered because you must find the right loop through all nodes.


Is there a natural phenomena, similar to the soap film exercise that would provide a solution to a given Traveling Salesmen problem?

I’ve been pondering this for the past few days, and I think the problem’s complexity lies in the ordering. Unlike Steiner Trees where nature “solves” for minimum distance by finding the lowest energy at an instant, here it would need to solve for the minimum distance over every ordered permutation of nodes. That implies iterations and time dependency, which reminds us of why this is NP-hard.

If we find a natural phenomena where things are traversed in a specific order which happens to be the optimal distance, we have a chance. At the moment, nothing comes to mind.

Being a SXSWedu Mentor

I had the privilege of being a mentor at SXSWedu 2016, and it was a valuable, rewarding experience in which I cannot wait to participate again.

The nuts and bolts

On my SXSWedu mentor profile, I listed a few topics which I could competently talk about:

  • Software development: Web, mobile, open-source, custom, CMS, LMS, etc.
  • Online community strategy
  • Agile development and product strategy

Because SXSWedu did such a great job of collecting a roster of exceptional mentors, I wondered if anyone would sign up to meet with me. So a few days before the conference, I wrote a SXSWedu staff member to inquire, and to my surprise a few people signed up to meet! I emailed them individually to say hello, and ask what they wanted to talk about so I could do some pre-thinking. A couple responded, which later made our short conversations that much more focused.

SXSWedu assigned me to a one hour time slot on Monday beginning at 5:00 PM. When I arrived (30 minutes early, as requested), I sat at a two-seat rounder table. When the first person arrived, a SXSWedu volunteer brought him to my table for our 10 minute chat (which flew by!) To keep everything on schedule, a volunteer indicated when we had 2 minutes left, and when we finished she brought out the next person waiting. Rinse and repeat for the next hour.

In retrospect

The conversations I had with each person were quick, but genuine. Every person asked a question related to the topics listed on my profile, so nothing hit me out of left field. In retrospect I truly feel I relayed at least one nugget of helpful information to every mentee. And while that alone instilled a sense of accomplishment, it turns out this experience morphed into an excellent networking opportunity. In fact, in a couple instances the other person and I decided to meet again after our 10-minute session to continue our conversation, which also led to ongoing email conversation. The mentor experience is an excellent opportunity to build relationships, and at such a large conference I love the chance to purposefully do so while helping others.