Two quick questions:
1) Product Sense: Is it better to start thinking of users, and then their problems? Or overall problems, and then possible user segments? Do you get dinged one way or the other? Or does it not matter as long as you are structured and have solid logic?
2) Product Execution: 'metric A goes up, metric B goes down'.. what's the best general structure for this execution problem?
Want to see the real deal?
More inside scoop? View in App
More inside scoop? View in App
blind
SUPPORT
FOLLOW US
DOWNLOAD THE APP:
FOLLOWING
Industries
Job Groups
- Software Engineering
- Product Management
- Information Technology
- Data Science & Analytics
- Management Consulting
- Hardware Engineering
- Design
- Sales
- Security
- Investment Banking & Sell Side
- Marketing
- Private Equity & Buy Side
- Corporate Finance
- Supply Chain
- Business Development
- Human Resources
- Operations
- Legal
- Admin
- Customer Service
- Communications
Return to Office
Work From Home
COVID-19
Layoffs
Investments & Money
Work Visa
Housing
Referrals
Job Openings
Startups
Office Life
Mental Health
HR Issues
Blockchain & Crypto
Fitness & Nutrition
Travel
Health Care & Insurance
Tax
Hobbies & Entertainment
Working Parents
Food & Dining
IPO
Side Jobs
Show more
SUPPORT
FOLLOW US
DOWNLOAD THE APP:
comments
A) start with audience segments and then go to pain points those segments would likely experience. That order helps to tailor your pain points to that specific segment. Be ready to offer experiments youβd run to validate success.
B) just have a structure you can articulate. What is the path to triangulating on the core issue? Internal feature team releases? Other adjacent feature team releases? External factors? Performance/load time issues? Etc... methodically isolate and check-in with your interviewer about assumptions s/heβd like you to make along the way.
Just my $0.02...
Good luck!