Formed in 2009, the Archive Team (not to be confused with the archive.org Archive-It Team) is a rogue archivist collective dedicated to saving copies of rapidly dying or deleted websites for the sake of history and digital heritage. The group is 100% composed of volunteers and interested parties, and has expanded into a large amount of related projects for saving online and digital history.
When we started Datical, we knew that in order to be successful we needed to practice what we were preaching: DevOps. As the VP of Products and product owner of Datical DB, our flagship Database Lifecycle Management tool, I recognize that Product Management is well positioned to facilitate DevOps adoption across the entire organization. It’s our job to ensure that the solutions we deliver to the market are aligned with our customers needs, valuable, and appropriately represented. To achieve this end, my team has embraced the Three Ways and established practices that map them.
The First Way: Systems Thinking
“Systems Thinking�? in the product management group goes beyond application development and delivery. Our PM team must also consider how we improve, market, sell, and support our solutions to fully realize our company’s potential. To gain the deep understanding of all aspects of our Product Lifecycle, we’ve agreed upon the following guiding principles:
- Every Sales Call is a Product Call – My team and I spend a lot of time shadowing calls in all stages of the sales cycle. By attending as many calls as we can we learn what first motivates our market to seek a solution in our space. We get insight into what features resonate most and what areas of our solution are uninteresting to them. We hear how our Sales team is positioning the product and we understand the challenges they face when presenting our solutions to interested parties.
- We Are a Required Member of our Scrum Teams – The PM & Engineering organizations are highly engaged with one another. Product & Engineering management meet 2-3 times a week to discuss sprint progress, new development stories, and long term product roadmap. Product Managers attend daily development stand ups to answer questions and eliminate roadblocks in the current sprint based on the needs of internal and external customers. We balance technical debt, infrastructure requirements and feature development during sprint planning to ensure high-quality product releases and a reliable delivery chain.
- We are Marketing’s Lyricist – Our deep understanding of our customers, our market, and our products allow us to arm our marketing group with the content and messaging they need to be heard over the chatter. We influence marketing plans with what we know is working in sales and what we know is coming out of engineering.
- Everyone is Customer Support – We take reactive and proactive participation in customer support seriously. PM responds directly to customer support requests and we constantly reach out to customers we haven’t heard from to make sure they are getting value from the product and that their needs are being met.
The Second Way: Amplifying Feedback Loops
The Second Way, Amplifying Feedback Loops, is where the product group provides the greatest value to the company. By adhering to our guiding principles of Systems Thinking detailed above, the product group has a good handle on all aspects of our business. We know how we sell, we know what we need to do to increase our value, we know the engineering effort involved in delivering new features, we know where our customers are thriving and where they are struggling, and we know what we’re telling the market.
The physical manifestation of the Second Way in the product group is our Product Roadmap. Too often, roadmaps become little more than flashy marketing tools that promise a lot, but often fail to deliver on the hype. We’ve found that customers respond more favorably to a smaller roadmap that is accurate than they do to a road map that is full of wild, cleverly named features whose delivery is uncertain at best.
At Datical, we take what we’ve learned from participation in sales and support activities to prioritize our development efforts on real customer needs. We apply what we’ve learned from engineering about the effort involved to deliver on our customer prioritized feature list, balance those estimations with what’s necessary to maintain a smooth operating environment for development, and provide realistic delivery goals for product features. Once we have dates for new feature delivery, marketing can plan their strategies ahead of time and sales can speak with confidence and certainty when discussing our future with prospects and customers. When every person in your organization can speak confidently about your customers, your product, and your market, the deck is stacked in your favor.
The Third Way: Embracing Experimentation
Product Managers that know their customer’s problems are crucial to reaping the most reward from Embracing Experimentation. A great example of this is a feature we are releasing in our 3.0 version of Datical DB this Friday. We call it the Rules Engine, and it is the direct result of Datical’s culture of encouraging experimentation.
Datical DB has a feature called Forecast that allows you to simulate your proposed database updates in memory without actually affecting the database instance. This takes the uncertainty out of the deployment process by identifying errors prior to execution. Customers really liked the feature, but there were always questions about the extent of Forecast’s capability. Typically they would ask about standards and best practices for their specific organization and whether we could modify the Forecast feature to accommodate their specific use cases. If we were to commit to modifying Forecast to suit everyone’s needs, it’s all we would have time to do. We recommended that the customers manually review the changes in those cases before promotion to downstream environments, something they were already doing with piece meal SQL scripts.
While discussing the frequency and consistency of these feature requests with our VP of Engineering, we had an idea. What if customers didn’t have to rely on us to modify Forecast for their specific needs? If we could deliver on this, we would drastically reduce the time and money companies were spending on reviewing database change prior to approval. We decided to turn our best minds on the idea with a very sparse set of loosely defined requirements.
Our first attempt failed. We reviewed the results of our research and prototype attempts, refined the story, and tried again. Our second attempt showed promise. We refined it further, built on what we learned, and had a viable solution in sight.
We began talking to our customers about it. I actually heard a grown DBA giggle with excitement! He had DBAs on his team spending 70% of their time manually reviewing SQL scripts from development to make sure they were in compliance with their standards.
After collecting customer feedback, we combined it with the results of our technical experimentation, and are very thrilled to be bringing this feature to market at last. By encouraging experimentation and not bowing to initial failures, we’re delivering a great differentiating feature to the market.
About the Author
Pete Pickerill is Vice President of Products and Co-founder of Datical. Pete is a software industry veteran who has built his career in Austin’s technology sector. Prior to co-founding Datical, he was employee number one at Phurnace Software and helped lead the company to a high profile acquisition by BMC Software, Inc. In addition to managing a development team and product schedule at BMC, Pete worked directly with large financial services institutions to provide the features they needed to achieve greater efficiency and cost savings in their application deployment processes.
