Business Founders Must Lead as Product Managers/Solution Architects

The title “Solution Architect” is a specific position in the IT hierarchy of a larger organization. Yet, in the context of a smaller organization, often early-stage startup, the role of a solution architect and related product manager is often at least partially filled by the founder and startup business leader. Here are some reflections on what I have learned about engaging as a product manager/solution architect in the software side of a startup.

Background

I want to be clear: I am not a developer nor am I a technologist. While I took programming classes in high school (that was a long time ago!), I have not kept up my coding skills and absolutely could not sit down and bang out some code today nor could I field all the technology tradeoffs in designing a technical architecture.

However, I have led multiple startup companies that had software as part or all of their solution. My startups have ranged from no software/pure hardtech to a 50/50 mix of software plus hardtech/science to pure-play software (aka tech) companies, so this post reflects lessons learned from how I have personally been involved in leading software solution development and how I have observed other startup CEOs/founders operate at the early stages.

Product Manager/Solution Architect in Smaller Organizations

Product Managers collect and represent the end-user perspective, define the product including both user and software requirements, create the product strategy and roadmap, and are deeply involved in collecting user feedback. They are driving the “why” and “what” underlying the product design.

In the IT world, a Solution Architect is responsible for creating an overall technical vision for a specific solution to a business problem. A successful Solution Architect leverages a deep understanding of the business domain plus an equally deep understanding of technical considerations. The Solution Architect also focuses on defining the “what,” while also defining “how” the product works internally to deliver that “what.” 

Unlike in a larger organization with a large IT department with many IT specialists, including multiple types of architects, dedicated product teams and soforth, in a smaller company with a lean team, everyone must spread out their role to cover the many responsibilities in developing a stellar solution. In that context, I have routinely slid into the role of both product manager and contributing solution architect. This post is intended to share a bit about those experiences because I think this is a common demand on founders that they need to embrace – at least for a while. I do not want to get into a battle about how to define the boundaries of all the possible roles that might be found in a bigger organization, but are not relevant yet in small, dynamic startup teams.

Lessons Learned and Success Factors to Consider as a Startup Business Leader

Consider the following when determining how to be a collaborative and effective leader of software development efforts:

• Synthesize and Articulate Clear Product Requirements: One of the most critical contributors to cost-effective innovative product development is the thoughtful development of clear requirements that, when realized, will delight future customers. Doing this successfully means investing your time in engaging and listening to many potential customers to understand their needs, priorities, and business decision-making context. Thorough customer discovery plus creativity is the foundation to building something that will matter enough to justify the price you want to charge for it. A solid set of synthesized requirements will guide your development team and enable smart tradeoffs as well as help layout a practical, testable development roadmap and inform user experience design. Staying involved in product testing and gathering user feedback along the way will help you guide the development process successfully. Remember that developing a deep understanding of the business problem at hand by gathering primary input and feedback will equip you to bring the most powerful perspective and needed guidance to a technical development team as you collaborate with your technical lead to chart the best path forward. 
  
  
• Remember the Technical Leader Should Lead on How Rather Than What to Build: The reason you do not want your startup CTO/lead developer taking the lead on what to build is that often the person who will be leading the process of embodying all of your innovative concepts in code has spent their career developing superb technical and coding skills rather than immersing themselves in broad industry context and customer discovery. It is simply a practical reality that when a technologist leads on designing a “solution”, the result can be driven more by technical considerations than customer needs. To achieve a great solution requires going deep in understanding the customer context, user needs, future-state business process and resulting product feature set demands strong communication and people empathy skills plus a relative insensitivity to the details of how the solution will be realized technically. This position is often a natural fit for the most customer-focused business partner on the team. Of course, designing and prioritizing the best path forward will be a dynamic synthesis of both perspectives best accomplished through a strong partnership and lots of collaboration between both sides.
   
• Become Conversant in the Relevant Technologies: As a business person, it is often easy to assume that the technical questions are someone else’s responsibility (possibly your technical co-founder?), however, while the strongest technical person on your team should likely take the lead in translating business and software requirements into an effective technical architecture because of the depth of the expertise, that is not an excuse to avoid learning about the major technical options and important tradeoffs between them. Ideally, the business and technical leads will collaborate and teach one another since both bring something to the task of figuring out the right answers. Learn the outlines of the tech stack your technical lead is envisioning, with an emphasis on understanding why certain elements are there. For example, learn high-level technical concepts such as the difference between a native app and a webapp, basic principles and types of databases, and when to consider on-prem versus cloud implementations. That means the business person needs to be willing to invest the effort to get up to speed on some of the essential decision points that will guide the technical design and the technical lead needs to be willing to help teach. While the technical decisions should ultimately be made by the technical lead, a conversant business lead will be in a better position to articulate the driving requirements and discuss the tradeoffs to arrive at the best approach collaboratively.
  
  
• Do Not Automate Prematurely: Embodying a design in code is a significant resource investment, so it is important to be mindful of when to commit to that investment. Often, there is a great deal of learning going on as an innovative solution is developed, so whenever possible, try to experiment with a design on low-investment paper and with somewhat clugey mock-ups (Figma!) or initial implementations to confirm that they work well before investing in a refined design. For example, before committing to an elaborately developed automated solution to handle a variety of potential exceptions, start with just generating an exception report with the relevant information for a person to review. Once enough transactions have been tried, it will become obvious what the critical decision points are, and at that point, some decisions can become automatic while others that actually demand judgment can have a user interface designed to efficiently capture those judgments. In other words, to avoid investing in lots of throwaway development and demoralizing your development team, make sure you are not asking for automation before the discovery process has occurred and the kinks have been worked out.
  
  
• Being Able to Articulate the Technical Big Picture and Rationale is Important for Fundraising: While potential investors explicitly do not expect a startup CEO to be the technical or scientific expert (in fact, it can be a warning flag if they come across that way!), it is crucial that a startup leader is appropriately knowledgeable about the core competencies their startup is built upon. That means that if innovative software is a critical component of your solution, the startup leader should be able to describe what is being built with a high-level articulation of why and how. Deeper details are an opportunity to showcase your technical or scientific leaders.

In small organizations, it is imperative that the founder and business leader be engaged in many aspects of defining and realizing an innovative, value-adding vision. This is not easy, yet small organizations demand a hands-on approach where everyone, including the CEO, collaborates to build together successfully. That means welcoming each person’s strengths to the game and being disciplined about driving forward well.