Context
Novelly is a digital library and reading platform for K-12 students, mostly middle and high schoolers, run by a nonprofit and funded by grants. I owned the entire web app as product manager, with two engineers and a designer, and worked with data science, marketing, curriculum development, and the nonprofit's leaders.
I was handed two goals, improve impact and improve accessibility, and neither was defined. I defined them with the founder and CEO. Accessibility meant a mobile-responsive product, so students who found Novelly on social media could open it directly on the web. Impact meant more books in the library being read, more users, and users reading for longer.
Constraints
- A $12K annual budget.
- The designer told me they could no longer work with us, even though they'd agreed to be available, so I had to hire and onboard a replacement while shipping.
- No way to collect user feedback, and work scattered across tools.
Problem
Students arriving from social media hit an account gate before they could read anything, which stopped new users at the door. The app wasn't set up for phones, and there was no feedback loop to hear what was breaking. Competitive research showed we weren't using web channels our competitors used to get discovered.
North starActive users, and how many library books they read and for how long.
Decisions
Remove the account gate
- Options
- Keeping sign-up first, or letting people read before making an account.
- Evidence
- A deep competitive dive across direct and indirect competitors: how they onboarded, and which web channels they used for discovery.
- Chose
- Remove the gate so a student who finds a book on social media can just start reading.
- Didn't build
- A gated experience with a nicer sign-up form.
- Cost
- We collected less about visitors up front.
Mobile-responsive web, not a native app
- Options
- A native mobile app or a responsive web app.
- Evidence
- Our new users were arriving from social links and needed to open the product straight from the web.
- Chose
- Make the existing app and web app mobile-responsive.
- Didn't build
- A native app.
- Cost
- No app-store presence and no home-screen icon for regular readers.
Replace the designer without stalling
- Options
- Pausing design work or hiring a replacement.
- Evidence
- Two engineers were waiting on design to keep shipping.
- Chose
- Lead the hiring myself, onboard the new designer, and work with them alongside the two engineers.
- Cost
- Weeks of my time went to hiring and onboarding instead of the roadmap.
Build the feedback loop myself
- Options
- Leaving bug reports in email and chat, or one pipeline.
- Evidence
- There was no way to collect feedback, and work was fragmented across tools.
- Chose
- An automated pipeline where a bug a user submits becomes a draft ticket in Notion. I review each one and assign it to engineering. I also moved the team's fragmented work into Notion.
- Cost
- Triage went through me, so I was a bottleneck.
Solution
Together these shipped as five releases, including a share feature. I also aligned the product roadmap with a grant that mattered to the nonprofit, and we secured a pivotal grant from a partner the organization had wanted for a long time.
Outcome
Users doubled over the eight months after I started, following the removal of the account gate alongside the mobile-responsive work. We shipped five releases, hired a replacement designer, put a feedback pipeline in place, and secured the grant.
I don't have numbers for reading depth (books read or time spent reading) to report.
Do differently
- Instrument reading depth from the start, so 'more reading' is a number.
- Hire a designer earlier or keep a backup, so a single person leaving doesn't stall the team.
- Test the gate removal against a control instead of relying on a before-and-after comparison.