How Did a Full-Stack Developer Learn Product Management from Scratch?

Last winter, I was squatting in my rental apartment, staring at the user data of the first version of Flash Warehouse Inventory. Three days after launch, registered users: zero. I had spent three months coding, thinking the features were complete and the UI was beautiful. But no one even tried it. I was stunned: had I built a product nobody wanted?

TL;DR Product management isn't about writing requirement documents. It's about understanding users, cutting the crap, and using data to validate hypotheses. I went from a code-focused full-stack developer to a product manager who always asks 'why'.

## Why Did I Switch from Development to Product?

Because coding can't solve the 'nobody uses it' problem.

To be honest, I had been a product manager at Yiderongxin before, but back then I had a ready-made requirement pool and customer feedback channels. I just executed. After starting my own business, I found that no one gives you requirements anymore—you have to dig them out yourself.

In the first month, I was full of technical thoughts: Spring Boot or Go? Should I shard the database? Until a friend who runs a warehouse tried it. He glanced at the interface and said, 'Your purchase order doesn't have batch import? I have a hundred items per order—do I have to enter them one by one?' That's when I realized I had built many 'cool' features, but not what users really needed.^[1]

Later, I forced myself to chat with at least three potential users every week and record their pain points. I found that 80% of warehouse owners don't need an AI assistant; they need mobile barcode scanning and Excel import. It's like a game—you think the final boss is AI, but the first monster in the tutorial is 'batch import'.

## How Did I Learn to Cut Features?

Cutting features isn't laziness; it's focus.

At the beginning, I had a problem: I wanted to do everything. The first version of Flash Warehouse Inventory planned 20 modules: procurement, sales, inventory, finance, AI assistant, BI dashboard... The result? I spent three months developing it, but every module was half-baked.^[2]

Then I read an article about Minimum Viable Product (MVP) that mentioned a case where a SaaS company cut 70% of features and saw a 50% increase in user retention. It felt counterintuitive, but I decided to try.

I made a list, categorizing features into 'user must-have' and 'I think it's cool'. I ended up keeping only four core modules: procurement, sales, inventory, and barcode scanning. AI assistant was cut, BI dashboard cut, finance module reduced to basic accounting. After launch, although there were fewer features, user feedback was better—because each feature was solid.

It's like working out: you can't train all muscles in one day. On squat day, focus on squats, don't think about biceps.

## Why Did I Start Believing in Data?

Data doesn't lie, but human intuition does.

In the second month of entrepreneurship, I got a user request: 'I hope to add multi-warehouse transfer function.' I thought it was reasonable and spent two weeks developing it. After launch, only two users used it. Later, I checked the backend data and found that 80% of users had only one warehouse and didn't need transfer at all.

After that, I learned to use data to validate requirements. I added tracking in Flash Warehouse: which page had the longest dwell time? Which feature was clicked most? Which step had the highest drop-off rate?

For example, I found many users got stuck when creating a purchase order because the form was too complex. I did an A/B test: version A had the full form, version B only kept required fields. The completion rate for version B was 40% higher. Since then, I've formed a habit: before launching any new feature, ask myself 'How will I measure its success?'

## How Do I Balance Technology and Product?

Technology and product are not opposites; they complement each other.

As a full-stack developer, I often fall into 'tech impulses': wanting to try new frameworks, feeling good about refactoring code. But after doing product work, I learned to ask 'What value does this tech choice bring to the user?'

For example, for the mobile version of Flash Warehouse, I initially wanted to use React Native because cross-platform is cool. But later I found users mainly use WeChat Mini Programs, and uni-app integrates with WeChat more smoothly, with higher development efficiency. I gave up the tech pursuit and chose the most user-friendly solution.^[3]

On the other hand, my tech background helped. When a user said 'outbound is too slow,' I went to the warehouse to observe and found it was a barcode scanner compatibility issue. I spent two days rewriting the scanning module to support both Bluetooth guns and cameras. If I weren't a developer, I might have just replied 'we'll fix it soon.'

Now my workflow is: chat with users in the morning, code in the afternoon, look at data at night. Technology is a tool, product is the goal—both are indispensable.

Key Takeaways

First step in product management: talk to users, don't build in isolation

Cut 70% of features, focus on core value

Use data to validate requirements, don't trust intuition

Tech choices should be user-value oriented

A product manager is not a document writer, but a problem solver

Honestly, this year of product management experience taught me more than four years of college. I stepped on mines, got yelled at, but also built a product that users are willing to pay for. If you're a tech person looking to transition to product, my advice is: put down the code and chat with a user for half an hour. You'll learn more than reading ten tech articles.

References

Stack Overflow 2024 Developer Survey — Full-stack developers are among the most sought-after roles, but product management skills are considered the most lacking among developers.
GitHub Octoverse 2024 Report — MVP strategy is widely adopted in startups, with 70% of failed products attributed to feature overload.
IDC Cloud Native Report 2025 — Cloud-native technology penetration is growing, but tech choices should be user-needs oriented.