Technical Contributions as a PM: HTML and CSS
This series is about technical contributions as PM — when and how to make them, and a few examples of contributions to inspire ideas. We’ll start with a couple of quick notes on when and how to make them, and then dive into specific examples.
Part 1: HTML and CSS ( + a little javascript)
Part 2: Ruby Liquid and SQL
Part 3: APIs and Webhooks
Part 4 : Javascript functions
Why should a PM be making technical contributions of any kind?
The core value-add of a software product manager is to discover problems that are valuable, usable and feasible. More on why here. This is where a PM should devote the majority of their time. Many daily activities directly support this type of problem discovery: analytics, customer interviews, competitor analysis, business model development, usability testing and using the product.
There are additional activities that are important to product delivery that do not directly support this critical discovery: facilitating team op-mechs, release coordination and communications, reviewing marketing and support materials, developing internal documentation. Though important for better product delivery, these should not come at the expense of problem and product discovery, in the same way that beautifying investor presentations shouldn’t come at the expense of producing customer experiences for UX designers, or writing email Scrum updates shouldn’t come at the expense of producing working code for engineering.
This principle holds true for any technical contributions. They can add lots of value, but they should not detract from problem discovery.
With a keen eye on prioritizing your time with the needs of the business, I’ve found many opportunities arise throughout the product development lifecycle to help make your product experience better and faster, when you’re not shy about getting your hands dirty and filling in the gaps.
Apart from the specific needs for a given use-case, there are several overarching reasons to not shy away from contributing technically as a PM:
- Be scrappy in unblocking work at all costs: There is always more work than can get prioritized right away with engineering. Getting lower-priority work out into customers’ hands faster accelerates your time to benefit and time to learning.
- Focus engineering on core functionality and differentiators: Sometimes, technically lightweight experiences are critical to achieving your product’s goals, but you know your team could deliver more if they were focused on your product’s core differentiators.
- Ship experience enhancements that otherwise would not get prioritized: Often the “experience layer” or guidance veneer of a product is the last to get prioritized. Things that explain how features work, or help customers adopt and enjoy them, often land lower in prioritization.
- Develop engineering empathy: It’s valuable to gain a firsthand understanding of how engineers work and bring ideas to life. Delivering working code to your customers involves many complexities that engineers are intimately familiar with, but that aren’t often well understood by their non-technical team members.
- Respect of technical team members: Not being afraid to learn technical skills can garner the respect of your more technical team members. Doing whatever it takes to improve the customer experience sets an example that can elevate the commitment to your customers across the whole team.
- It’s personally rewarding: It feels great to deliver a tangible output directly to customers, as opposed to facilitating work for designers and engineers. Stretching your technical muscles and learning how software gets made can be very gratifying.
Different scenarios bring situational benefits for contributing directly, as well. The needs of the business and the customer are always evolving, bringing with them new opportunities to help the team by contributing technically. I’ll illustrate a few examples of these below.
The problem: need simple pages that explain how features work
I work at a FinTech digital bank startup, One, focused on building the future of banking for middle-class Americans who are underserved by incumbent banks. Our value comes from what we can do with our customers’ money: saving more of it, providing lower-cost credit, helping them bridge financial gaps and understanding how their money moves.
As such, when building out our roadmap, we focused first on the riskiest, most fundamental core functionality components of our banking app, before onboarding and activation experiences that explain how these features work and how to use them. This is where our engineering teams can add the most value to our customers’ lives.
Our company was also trying to learn from early beta testers of the product, but our experience was missing the “glue” of activation experiences that guided customers in how to use our product and could help facilitate organic feedback. This, in turn, would help the company understand if early low-adoption rates were because A) our features weren’t providing value, or B) were providing value, but were hard to use and understand.
We needed to answer these questions as quickly as possible, but it would come at the expense of other core banking functionality that helps our customers even more. We designed onboarding and first-time-use experiences to help new customers understand our core features, but we had to decide when to prioritize them against the other critical work in our backlog.
The opportunity
We implemented a tool called Braze, which allows us to deploy targeted messages using prebuilt messages or custom templates using HTML, CSS and Javascript to engage customers at various points in our app.
The prebuilt templates didn’t match our designs and were a little too rigid for the onboarding experiences we worked up with our design team. This left us to either build our own custom templates, or hand the work off to engineering to build natively.
After determining we could deliver the same quality experience through our own custom HTML and CSS experiences through Braze, and evaluating the trade-offs in our backlog, the opportunity to build these experiences and allow engineering to focus on other work seemed like the right call. We’d get the experience out faster than if it had to compete with other bodies of work in the backlog that delivered more value and were higher risk. And it would allow the team to focus on our core differentiators.
Getting your hands dirty
Our goal was building a set of onboarding and first-time-use screens that would guide customers on features within our mobile and web apps.
The process
- Started with finding templates online that were close to what we had designed.
- Brushed up on needed HTML, CSS and JS through free online classes/resources in spare moments between items at work (highly recommend w3 schools).
- Closed feedback loop with design. When you’re not 100% confident in your ability to match the design 100%, make sure you have a tight feedback loop with design to course-correct early and often.
The product(s)
- A pre-signup carousel explaining the benefits of our app to customers before they sign up:
- A welcome carousel onboarding customers once they sign up:
- Contextual drip and nurture calls to action to complete critical onboarding actions:
- First-time-use screens for each feature explaining the benefit and how to use in context:
How it worked
- CSS styling code captured in Figma:
- Starter templates, style sheets and needed javascript files copied online from Github:
- HTML templates and CSS styling built locally and hosted by Braze:
- Javascript for template swiping and interactions hosted by Braze: https://github.com/kenwheeler/slick
- Triggering in-app power by segment events we’ve instrumented that invoked the Braze SDK to trigger the hosted messages:
The results
We saw spikes in all our core early-use metrics: 7-day retention, % of new accounts funded and % of new accounts spending, as well as increases in feature adoption and multifeature penetration.
Most importantly, we were able to quickly validate with real data which early features added value but suffered from usability barriers, and which lacked customer-appeal full-stop — all while keeping engineering focused on some of our bigger swings.
What worked well
- Time saved for engineering and time-to-benefit for customers: We were able to save a full sprint focusing on core money-movement differentiators and get these screens out weeks before we would have been able to prioritize them.
- Ability to rapidly make changes outside the engineering cycle after release: We received lots of feedback right after the release, which culminated in several content and image tweaks that were easy to deploy without having to get prioritized in the engineering cycle.
What could have been improved
Leaving time for revisions …
- We were able to get the visuals to match, but supporting language localization, accessibility and responsive design took more time than anticipated at the end.
- Don’t shy away from asking engineering for help, so as not to spend 90% of you time on the last 10%.
- There were 2–3 adjustments with the javascript and visual styling that took 90% of the time to be resolved. I waited a bit too long to ask engineering for help, and I would have saved tons of time asking for help a bit earlier on in the process.
Building these experiences was a win all around. It was fun and rewarding, and it helped our customers, the business and our engineering teams.
Disclaimer: It is, perhaps, easier to find opportunities to contribute at a startup, where resources are scarce, and everything is urgent. And there is always a better technical expert at a bigger company to get these types of tasks done. Even so, being able to unblock your team or initiative is crucial, and PMs should be willing to do whatever it takes — and wear any hat to do so. This need exists at companies big and small. In my experience, there is a bit more process to fight through when contributing at a bigger company, and the standards for contribution may be higher. But if you’re committed to delivering the quality the project demands, diving into these projects can be very rewarding while garnering better results faster. As for the process, asking for approval rather than permission by presenting finished projects that demonstrably deliver the value your team wants trumps any processes or territorial lines over who owns what.
