Last newsletter of the year!

Author

Irene Yu
December 22, 2021

Hey, it's Irene here! 👩‍💻

Popping in your inbox with the last edition of the Skiplevel newsletter before 2022 is upon us (where did the time go?!).

This last newsletter is chock full of goodies including a $35 coupon code to welcome the new year, my new podcast episode on becoming technical with Jason Knight from One Knight in Product, tips on writing requirements for your dev team, and an intro to Elasticsearch.

Wishing you and your loved ones a happy holidays and a fantastic new year! ❄️

Know someone that would like this newsletter? Share it with your friends by forwarding them this email!

💡 To welcome the new year, use coupon WELCOME2022 for $35 off the Skiplevel program. Check it out before it expires on 12/31!

Writing requirements for your dev team

Recently, a product manager in the Skiplevel community asked for tips on writing stories/requirements to help developers make better decisions around improving latency. What a great question!

The business requirements doc (BRD) and user stories are the two main ways we collaborate with dev teams to build out features/apps, so it goes a long way to get it right.

While I have quite a few tips to share, here are 3 from my personal experience as a dev working with BRDs and user stories.

#1/ Less words, more diagrams. I've worked with text-heavy BRDs and diagram-heavy BRDs, and suffice to say, the text-heavy BRDs are painful and overwhelming. To make your BRD more helpful and easily digestible to everyone on the team, use diagrams instead of text as much as possible.

For all complex if/else logic requirements, create a simple user flow diagram. For metrics and business decisions, use decision tree diagrams. As much as possible, include the UI/UX mocks from your designers. You can use text to expand, clarify, or add additional information to your diagrams, but make sure to label them all so your readers can quickly reference a diagram (i.e. Fig. 1).

#2/ Write requirements that are testable and/or observable. This means doing away with adjectives as much as possible and going for numbers, mocks, and flow diagrams. For example, if you want a page to load fast, specify an explicit load time as the requirement (i.e. 1.5 seconds). This way developers can run load tests during development and can provide you proof that they've hit your definition of "fast". This makes the requirement testable.

Here's another example: if you want the app to look "nice", provide well-made UI mocks that include the correct font, spacing, and colors. This way you have visual proof that the product looks the way it should (observable).

#3/ Requirements should be presented in phases & priorities. Developers not only need to know what to build, but also when to build it and when expected delivery is. It's ok to include all your grand ideas for the short and long term goals of your product in one BRD, but break them down into phases and priorities with clear timelines.

This means your user stories should be labeled as P0,P1,P2 , and the user stories should be categorized into their individual phases for when they should be delivered.

New Podcast Episode!

Fast, scalable & relevant search with the Elastic stack

💡 The next three newsletters are dedicated to learning the ELK stack (Elasticsearch, LogStash, and Kibana). This newsletter introduces what search is in data, and Elasticsearch.

What is Search in data? 🔎How long would it take you to identify all the products that contains the letter 'b' from this list of 7 products? ["Bottle", "Tablet","Dresser","Hairbrush","Toy truck","Swing set","Apple Cider"]. Probably a second. Now imagine a big e-commerce store like Amazon that sells millions of products. How long would it take you to filter through those products? Chances are you wouldn't even try!

While computers can search faster than our feeble human brains can, they still struggle to filter through the trillions of bytes of data companies receive. For companies with big data who rely on search for their business needs, this is a problem that their development teams need to solve. So how do they do it?Search and Analytics Engines: Introducing ElasticsearchDevelopment teams typically integrate with third party search and data analytics platforms for searching capabilities. A popular solution used by many engineering teams is Elasticsearch, an industry leader in search and analytics ever since its launch in 2010.

Elasticsearch allows us to store, search, and analyze huge volumes of data quickly and in near real-time. They do this by indexing* data which makes searching data much faster. Elasticsearch is also known to be reliable/fault tolerant due to its automatic replication* of data on multiple nodes. It also has REST APIs and a UI to perform CRUD* and search operations in the cluster*–making it easy to use.

How data gets stored & indexed in Elasticsearch

Want to deep dive into Elasticsearch with a demo? Watch this video from the Official. Elastic community.

💡 Definitons of tech terms*:

CRUD: Stands for Create, Read, Update, Delete. Common tech terminology for working with data and API operations.Cluster: Group of two more servers (physical or software) that act like a single system. Ex: 3 of the same servers hosting the same application for horizontal scaling.

Node: A specific server in a cluster (Could be physical or a VM).

Replication: Process of making multiple copies of data and storing it in different location for backup purposes. Part of a fault tolerant design.

Data Indexing: Segmenting data into logical groupings (i.e. toys, furniture, gift) allowing quick retrieval of data vs. querying through an entire data set.

Know someone that would like this newsletter? Share it with your friends by forwarding them this email!