Saying that it locks the whole table is incorrect, basically. But we need to be more detailed that so in order to give a usable answer:
SQL Server need to be able to find the rows, both for the UPDATE and also for the other SELECT (I assume you are trying to read rows while the UPDATE transaction is open). If you don't have an supporting index for any of the elements in the WHERE clause, then below will happen for every row in the table. If you do have an index, below will happen only for the rows that SQL server need to read, based on the index it chooses to use. This applies for both the UPDATE and the SELECT.
For the UPDATE, for every row it has to read (see above) it will acquire an update lock, check if that row satisfies the WHERE clause. If it does, then an exclusive lock will be held and the update lock will be released. The exclusive lock will of course block others that try to do SELECT. I assume pessimistic concurrency here, which is the default for on-premise SQL Server.
For the SELECT, for every row it has to read (again based on what indexes that exists), a shared lock will be acquired and SQL Server will see if that row satisfies the WHERE clause of the SELECT. If it does, then the row is returned, if not, the shared lock is released and SQL Server moves on to the next row (I assume the default isolation level here, READ COMMITTED).
So, if you have no indexes to support the SELECT, it need a shared lock on every row, to see if that row will be returned. But the UPDATE if course has an exclusive lock, blocking that read. This happens even if the SELECT in the end try to read a different row than the one you updated.
Here is code you can play with, just post back if you want to expand on the discussion:
DROP TABLE IF EXISTS t
GO
CREATE TABLE t(c1 int identity, c2 char(5) default 'hej')
INSERT INTO t
SELECT TOP(10) 'hupp' FROM sys.columns AS a, sys.columns AS b
BEGIN TRAN
UPDATE t SET c2 = 'tjoho' WHERE c1 = 5
--Do this SELECT from annother session. It will be blocked.
SELECT * FROM t WHERE c1 = 7
--Study locks, from yet another session
SELECT * FROM sys.dm_tran_locks
WHERE resource_type <> 'DATABASE'
AND request_mode NOT IN('IS', 'IX')
ORDER BY request_session_id
--When we are done
ROLLBACK