Joyful Product Management

Transforming a side project into a career

For the past several months, my business partner Andrew and I have been spending nights and weekends building software products for clients using codeless tools. It’s been exhilarating and exhausting, and we’re looking forward to continuing this work on the side. This post shares our experience and many of the things I’ve learned along the way.

Now, I am looking for work as a Product Manager.

Why? Nights and weekends managing my own products convinced me that using lean startup practices, user-centered design, and agile development is a great way to build software — but I’m equally convinced I have so much more to learn. I would like to surround myself with a larger team of experienced and knowledgable people.

I’d like to turn my night job into a day job so I can learn more deeply, share my experiences, and empower others to use the modern development practices I find so valuable.

So, if you’re hiring, and the learnings below resonate, let’s talk!

Andrew Gassen and I launched Joyful Literacy Online this month. Our web application allows teachers to save time and effort incorporating Dr. Janet Mort’s Joyful Literacy curriculum into the classroom. Dr. Mort has decades of teaching and research experience, and her curriculum is in use by thousands of teachers in North America. Dr. Mort’s research proves that, with this curriculum, children can read at grade level by 2nd grade.

This, our first product, was the culmination of four months of user interviews, usability testing, development, and the administrative tasks of starting a new business. We are fast approaching 200 registered users. In October, we’ll get face-to-face feedback from potential users at conferences in Saskatoon and Calgary.

In the meantime, we are using the analytics on our site to validate the hypotheses we made when we launched the application into production and improve upon the platform. We are also soliciting feedback in the form of more user interviews and usability testing.

Real people are using our product. Something we built from scratch. It’s a really exciting time for us!

As I reflect on how we got here, I realize that I never considered to seek out a product management role — but in moonlighting a new business, I’ve learned many skills that would help me as a PM elsewhere.

Now, I’m ready to turn product management into a career.

I’ve seen product management up close in companies that focused on consumer research, advertising technology, and management consulting. I’ve read countless articles about the craft. I’ve now experienced it at my own little side-project startup, and launched a real live working product.

Here are the lessons I’ve drawn.

Talking with real users has no substitute

I have known and observed many teachers in my life. My sister is a teacher. Before I started interviewing our users (teachers), I believed I would have been able to predict 90% of what teachers would want. Boy, was I wrong.

Teachers pour their hearts and souls into their classrooms. While the standard school day is somewhere between 6–8 hours of teaching time, we know that teachers often work much, much more. Some estimates say teachers work between 12–16 hours per day on average.

With a little bit of this kind of research, we learned some things about teachers, in general.

We also learned that the Joyful Literacy curriculum was already being practiced in classrooms throughout Canada and the United States. In fact, Dr. Mort has a group of dedicated teachers who use the curriculum and Circle Charts (on paper) and act as research partners. We honed in on these folks as our target pilot users: they’re already using the curriculum, which meant they’d have the most to gain, and be the most critical, of any application we built.

So we set up time to speak with them. And we listened. We asked open-ended and perhaps under-appreciated questions like “tell me more” and “how does that make you feel?” Through this exploratory approach, we tried our best to put ourselves in their shoes and gain empathy for the teachers. And we learned, quite a lot, about what challenges you might face if, every day, you were teaching very young children how to read.

For example:

• “I spend a lot of time outside the classroom planning lessons and trying to figure out which students need the most help.” Assumption: if we can save time for the teacher, we immediately add value.
• “I’m always on the go, always on my feet during the day. But at the end of the day I’m usually on my laptop at home preparing lessons or reviewing my students’ work.” Whatever we build, it needs to be accessible on multiple devices.
• “I need to quickly glance and find out who needs extra help or what skills I need to reteach.” Seeing each student’s progress in relation to the rest of the class is absolutely imperative. As a corollary, the action teachers take is either: get a student (or students) more help on a specific skill, or re-teach a skill to the whole class.
• “The curriculum is easy and specific. I feel confident that the research is right.” There is comfort and confidence in Dr. Mort’s research; we’re not going to be able to improve that, but maybe we can help cut down the time it takes to administer, or make it a little more joyful.

We wanted the teachers to tell us a story, and they did just that. We asked them to commit to test-driving our software later in the summer, which they did. We learned about their pain points and insecurities, but also of their remarkable devotion to their craft and their students. We learned that our client had a wonderful and powerful product that people believe in.

We were energized by the opportunity to transform teachers’ experiences, and, indirectly, help more children learn to read.

Finally, a portrait of the highest needs began to emerge. We we ready to build our first best guess of a minimum viable product.

Planning and validating can be more important than development

I’ve written elsewhere about what Bubble is capable of, and why we think codeless tools are an awesome way to deliver value to users quickly and inexpensively. Bubble is the tool we used to develop Joyful Literacy Online, and it was a ton of fun getting to know how expansive Bubble’s powers are.

But defining and validating the problem are perhaps even more important to the success of an application than the way it is built.

From the interviews, we knew a lot about what the teachers wanted (and also what they said they wanted, which sometimes are different things).

We also knew we wanted to start by providing value with something we could build easily. The modus operandi? Deliver value quickly, learn, and get on a roll.

To illustrate, let’s focus on a particular feature teachers said they wanted: reports. We heard this over and over again: “I want to print out reports.” But reports in themselves aren’t necessarily valuable. The real value of reports is what teachers do with them. When we dug in further — and read between the lines — we gained insight about a variety of teacher needs.

As a classroom teacher …

• I want to quickly discover which students are in the bottom 20% of the class in mastering a particular literacy skill, so I can group them into a reading group and get them additional help.
• I want to quickly discover which literacy skills I have already taught to my class, but most of the class hasn’t mastered, so I know what skills I need to teach again.
• I want to be able to hand parents a piece of paper that shows them their child is way behind the rest of the class in learning the alphabet, so they spend more time reviewing the alphabet at home.
• I want to be able to show evidence to my colleagues and principal that I need additional help to get a particular student or group of students up to speed on a particular skill, so they agree to help me.
• I want to be able to create my own charts and metrics in Microsoft Excel or Word based on my student data, so I can demonstrate my own progression as a teacher.

Rather than raw findings, we now had synthesized insights upon which we could base our development. It’s worth noting that, had we not brought empathy to our user interviews, and if we had spent more time asking specific questions rather than broad ones, we may not have landed on these insights as quickly — or at all!

Boiling the ocean is an easy trap to fall into. It would have been easy at this point to attempt to build the biggest, coolest, most comprehensive report system ever. But that wasn’t our m.o. If you’ll remember, we wanted to provide value quickly with something we could easily build. We also wanted to validate that we were building for our users something that would actually work for them in real life.

The Joyful Literacy Circle Charts are an elegant solution to tracking student achievement because they are simple and straightforward. After tossing around a bunch of ideas, we settled on a simple count of students with mastery in each column. It took us 20 minutes to come up with the solution, and five minutes to build and deploy. It cost us so little in time that it made sense for us to push ahead and get feedback on the actual feature rather than spending time building a mockup or a prototype.

We then got reactions from our teacher users. “Neat,” one said, “I like that, it helps me figure out which skills I need to teach. Could you do the same for students in the rows?” Sure we can! Another five minutes of work, another release, and now we’ve doubled the value we added with this small feature.

Rather than charging forward with solutions to some of the other needs we uncovered, it made sense to re-engage with teachers at this point to validate what we learned. Outside of our column and row counter, we felt that new report features would take a not-insignificant amount of time to build.

We offered some potential solutions to a handful of our users, and this is what they came back with:

• Most important: something that let teachers print one single chart onto a sheet of 8.5 x 11 paper
• Next most important: some way to view student progress over time
• Maybe important, needs more validation: exporting data to Excel

Frankly, these results were a little bit surprising to us. In our interviews, it appeared that Excel exporting was really, really important. Not so, in comparison with other options. We may also have been a little biased towards the Excel export, because it was fairly straightforward to build. But feedback was unanimous: Excel was not a sure-fire way to add value to teachers.

Validating our understanding of the teachers’ problem saved us time we may have spent building something teachers don’t value. More importantly, it directed us towards something that does create value. The lesson?

Validation is doubly good, and it’s doubly good throughout the entire product development process: before you build, as you build, and after you deploy to production.

Let’s move on to something else that’s doubly good: pairing.

Pair for better outcomes

Andrew Gassen is a super great dude. (I wrote these words as a placeholder in my outline for this article, and honestly can’t think of any better ones to start this section.)

Conventional management wisdom separates teammates to each work on discrete tasks even if they have the same objective. For example, we interviewed multiple teachers — we could definitely have saved time by each interviewing different teachers one-on-one.

It might sound crazy, but pairing — doing this work together, rather than separately — can work so much better.

Andrew catches my mistakes super fast, and vice versa. We interpret the same things differently, and end up with better ideas as a result. Because we’re constantly pairing, there is no need to set time aside to review things — it just happens, in the moment.

Because we pair, we are able to always look forward, our sights never far from the horizon.

Pairing is faster, leads to better outcomes, and might even take less time. I’m a proponent, and I’m very thankful for Andrew’s support — and for all the things he’s taught me. (Thanks, bud!)

So, who’s hiring?

My professional experience has mostly been in client services. I’ve conducted software-based consumer research programs, got companies to pay obscene amounts of money to show you ads on the internet, and introduced modern management practices to the federal government.

The last four months of planning, validating, and building Joyful Literacy Online have been unarguably the most interesting and exciting of my career.

I put “Co-Founder & Product Manager” at the top of my resume, because this experience as a startup owner makes me feel confident in my product management abilities. Better Product Company — and our Joyful Literacy client — is an awesome, instructive, challenging, and fascinating side project. I enjoy learning from this experience immensely, and I don’t think I’ll give it up.

But, at the same time, I am ready to level up. I’m ready to surround myself and learn from experts. I’m ready to do product management work 40+ hours per week, 52 weeks per year — instead of some hours, in the evenings, when I’m not otherwise engaged.

If you are ready to set your sights on the horizon and build some awesome software products with me, I invite you to contact me. Let’s build something great, together!

alex@betterproduct.co