My First 60 Days As a Product Manager at OpenGov

This post outlines what I've learned and experienced as a consultant product manager for OpenGov—a high-growth tech startup in Silicon Valley.

When Peak Democracy merged with OpenGov in October, I found myself transitioning into a new role as Product Owner and Manager for Open Town Hall—Peak Democracy's flagship product. The mission of Open Town Hall is to build public trust in government for the good of society.

We do this by building tools for local governments to receive input from their residents on community issues. By creating a constant stream of structured communication between people and their government, we help decision makers take into account the needs of all their residents—not just the ones with loud voices who show up at public meetings.

I've learned a lot from the challenges we've faced over the last thirty days as the two organizations have come together on shared mission to make government more effective and accountable.


To structure my thinking, I've broken down my experience into different chunks:

  • Organisms
  • Architecture
  • Design
  • Process
  • Culture & Communication


Organisms Peak Democracy was a small 10 year-old company that was self-funded, consistently profitable and fully remote. It had no physical office and consisted solely of a small cross-functional team of remote collaborators. It was lean, resourceful and as one of the founder often said, "scrappy."

OpenGov is a five year-old, 180+ employee, venture-backed startup that has achieved product-market fit and is growing quickly as it scales processes and teams. It is headquartered in Silicon Valley with engineering offices in Portland and New York.

Peak Democracy merging with OpenGov has been like a small single-celled bacteria being absorbed into a complex multi-celled organism.


Architecture As two software companies whose models center on selling annual subscriptions to governments, you'd think that it would be easy to merge a small product into a platform with several products. But, as my Dad always says "Nothing is ever as easy as it seems".

In order to integrate Open Town Hall as a product within the OpenGov suite, we're having to rearchitect the entire application. At the same time, we're redesigning the UX from the ground up to address usability issues in the legacy application while building new features to address unmet user needs.

Monolithic vs Service Oriented Architecture

The architecture of Open Town hall at Peak Democracy was 'monolithic'. It's like one large cube with one stream of inputs and outputs. It's a Ruby on Rails application with one server, one database and not much more...

This monolithic architecture is great for start ups who want to achieve product-market fit with as little resources and friction as possible; however, it has severe limitations when it comes to performance and scaleability. This is a major concern for a high-growth tech startup.

OpenGov achieved product-market fit by building individual prodcuts with 'monolithic' architectures, but as they found the fit and began to scale, they needed to rearchitect to provide trajectory for the rapid ensuing growth. As a result, they've developed an architecture that addresses these problems for their products at the same time.

This solution is known as "Service Oriented Architecture" (SOA). If "monolithic" architecture is like a large cube, "service oriented" is like a matrix of tiny cubes. Each tiny cube is referred to as a "micro-service" with a unique set of responsibilities, data and concerns.

Benefits of Microservices

This architecture allows for the system to react dynamically to a variety of demands: volume of requests, security, resource, data access, etc. For example, imagine a cube with a specific responsibility is painted blue. As a monolithic cube, it would fail to respond to 20,000 requests per minute (requests = users trying to access the service).

But, if implemented as a microservice within a Service Oriented Architecture, the system can identify that the blue cubes are receiving a high volume of requests and scale up the system to meet the requests. It would create more blue cubes and deliver more resources in real-time to match the demand. If one of the blue cubes crashes or goes offline, the system will spin up more instances to meet the need.

This allows the system to deliver its services according to real-time needs—creating a more robust, scaleable, and performant product—one that can meet the demands of the residents of a capital city trying to access a given web page.

This kind of architecture seems to be an emerging pattern amongst software startups trying to "Cross the Chasm" (Geoffrey A. Moore uses this term to describe the transition from niche to widespread adoption and the leap it requires companies to make). I'm so grateful to have gotten an opportunity to see it from the inside.

Flying the plane while you build it

As soon as I learned about this approach, I was really excited to get Open Town Hall integrated with OpenGov's platform architecture.

But as with most things in technology, everything is constantly evolving and growing. The blueprints for OpenGov's service oriented architecture have been drawn, but only a couple of their products have been rearchitected accordingly. Even still, many of the technology components are evolving or have yet to be decided.

With each architectural component that makes the system work, there are dozens of dependencies, new languages and paradigms. Each aspect of a new system presents complexity to a new team who is learning to speak a language that no one speaks fluently yet...

Trying to migrate our monolith into their ever-evolving platform architecture is like trying to fly a plane while its being built AND designed. Oh, and all your passengers have paid a lot of money and expect to arrive on time....



So here we are as a single celled bacteria trying to merge into a large complex organism—flying a plane while we learn how to build it... also, the plane needs to look and feel like the other planes in the hangar. And it needs to be usable for governments and their public. Accessible. International. Mobile-first. Intuitive. Comply with legal concerns of free speech rights and others.

That's where design comes in. At Peak Democracy, I was working with an amazing UI designer and Front-End Developer named Paul Lloyd who has over a decade of experience solving these kind of problems. We knew each other from our time at Clearleft—a leading design agency who has been talking about accessibile, mobile-first and pattern-led design for a long time now.

We were just kicking off our 'design system' project when OpenGov entered the scene. So along with our technical rearchitecting, we're having to align our design patterns, principles and components in such a way that addresses all of the problems above.

The complexity of these issues is astounding. Working as a PM has allowed me to grapple with the problems of both engineering and design at a decent depth. It's amazing to see the skilled and talented individuals in each set of disciplines address these problems with their unique tool sets.



As long as I've worked as a designer, I've been a big fan of optimizing processes to minimize waste and maximize output. Having gotten into Lean through personal productivity and startup validation, it's principles have permeated everything I do.

At OpenGov, they've applied a rigorous process design to everything within their organization. Like the technology, the processes are designed for quality, scaleability and performance. It's an organization full of people, but it needs to operate like a machine with timely and reliable delivery of value to its customers.

It needs to innovate and be stable at the same time. It needs to address current customer needs and future customer needs.

The processes that envelope the execution of this machine are all encompassing and informed by OpenGov's executive staff and their wide range of experience in starting and scaling startups.

It's been fascinating to watch some of the best people in the industry do what they love most. Hopefully down the road I can write in greater detail about process design and dig a bit deeper to uncover more lessons myself.

Culture & Communication

Culture & Communication

My time at Clearleft instilled in me the importance of understanding a company's culture and being intentional about communication when trying to solve problems in collaboration. Digital transformation is more about the informal connection between humans than it is about the technology. How people define problems, create shared understanding, develop empathy, generate ideas and test solutions is integral to their success. The specific technology they use is an element, but it usually comes afterwards...

Mortimer J. Adler describes the process of "coming to terms" when reading a new book. Having worked in an agency and as a freelancer for my whole career up to now, I've learned how to come to terms with the vocabulary and jargon of each company I work with.

It's been fascinating to learn the terms of Silicon Valley through OpenGov and understand how the language used reflects the mindsets and worldview of its speakers.

There's a shared belief being cultivated that is a byproduct of a lot of brilliant minds giving their all to solve complex problems in a financially sustainable way.

The language that has emerged is a mix of lean manufacturing, agile engineering, design thinking, customer support, enterprise sales and government procedures. Lots of acronyms and abbreviations. Metrics and measurement is key...

It's a great example of how far people can go in their collective identity when fueled by a shared belief and shared mission.


Every day I learn about a new tool, a new discipline and a new obstacle. I learn something new from every conversation. Just when I feel like I've finally gotten comfortable with the level of complexity I'm facing, something else emerges. As soon as I can reliably juggle three things at once someone tosses in another two...

I guess this is the kind of environment where you sink or you swim. You learn how to run fast or you fall.

This has been 60 days as a Product Manager at a Silicon Valley tech startup (consulting remotely with an 8-hour time difference). If this doesn't teach me what I need to solve complex social problems at scale, I'm not sure what will.

I'm so grateful for the opportunity I've been given, the incredible people I've